Skip to content

Connection pool #411

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 10 commits into from
Jul 19, 2016
Merged

Connection pool #411

merged 10 commits into from
Jul 19, 2016

Conversation

kdubb
Copy link
Contributor

@kdubb kdubb commented Apr 16, 2016

Implement simultaneous multi reader, single write connection pool. Uses WAL and exclusive VFS mode to achieve concurrency.

kdubb added 6 commits April 15, 2016 22:23
Uses WAL mode to support multiple reads and a single writer.
Allows customizing new connections once created
ConnectionType is now Connection and Connection is now DBConnection
vfs seems to be a more reliable handling of exclusive mode.


/// Protocol to an SQLite connection
public protocol Connection {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per the Swift naming guidelines can we make this ConnectionProtocol and retain the default Connection class name?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't ConnectionType be more Switfy? (thinking of SequenceType, etc)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't kept up on the Swift-Evo list as of late. I know they are renaming basically everything.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I kind of liked having DBConnection, regardless of the protocol name, simply because it has more capabilities than the protocol does and the name kind of explains why in that case. Although, with a renamed protocol, simply Connection works as well.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, this is the proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md

Strip Type suffix from protocol names. In a few special cases this means adding a Protocol suffix to get out of the way of type names that are primary (though most of these we expect to be obsoleted by Swift 3 language features).

I need to go back and update the other Type-suffixed protocols, as well.

Copy link
Contributor Author

@kdubb kdubb Apr 17, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given this I'd love to keep it as is. Connection, DBConnection & BorrowedConnection (although you never use it directly) are more descriptive and seem to be more in line with the eventual Swift naming schemes; the alternative of ConnectionProtocol, Connection & BorrowedConnection seems less desirable to me even if it means a bit of renaming in projects.

In reality, projects shouldn't have to do much renaming at all since Connection just becomes a protocol. Only during initialization & when using special functions would you need to use DBConnection.

Copy link
Owner

@stephencelis stephencelis Apr 17, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we can find another, happier medium. The reaction I had to the current naming direction is that it's a little harder to derive specific meaning on its own. I'm left wondering why only one of the types is prefixed with the abbreviation DB and what the significance of DB has over the other types. I also wonder if decorators like DB are slightly redundant in a SQLite library.

I actually prefer ConnectionType over ConnectionProtocol, but was trying to move in the general direction of Swift norms. I wonder if we could come up with a different protocol name that we like even better. Or maybe DBConnection could change to something else, like ConcreteConnection, though that descriptor still seems slightly confusing to me.

Any other ideas?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that 'DB' wasn't the best. Prior to that I had almost settled on DirectConnection. Which may be more to your liking?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup! Definitely prefer that! Has very clear meaning on its own.

@stephencelis
Copy link
Owner

This is great! Naming/delegate question aside, I'd love to get this merged!

@kdubb
Copy link
Contributor Author

kdubb commented Apr 18, 2016

@stephencelis Updated to use setup closures very close to your suggestion. Like it much better. Also renamed to DirectConnection

kdubb added 2 commits April 18, 2016 18:02
Was using incorrect dispatch_once token.
# Conflicts:
#	SQLiteTests/ConnectionPoolTests.swift
@stephencelis
Copy link
Owner

Looking good! Going to check it out and put it through some tests before merging.


var borrowed : BorrowedConnection!

repeat {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this a busy loop? If all the readers are checked out it would appear this method will just keep repeating busily until one is available. Would be a lot better to use a dispatch_semaphore or NSCondition to let it sleep and get a signal when a connection is actually available.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be honest I need to look at this again... This seems to be a holdover from an earlier version/feature. This code should find an available connection, wait for one or fail. None of that requires a loop. Good catch!

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now because it will always create a new reader it'll never busy loop, but if it didn't it would create a busy loop just need a signal of some sort…

You also want to make sure that signal isn't does block the lockQueue otherwise a connection wont be able to be checked in.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did this in 960309e and would appreciate any feedback.

@nickmshelley
Copy link
Collaborator

@kdubb: Is there something I can do to help get this through? I don't want to step on any toes but I'd love to see this in and am willing to finish up whatever's remaining if you're too busy at the moment.

@nickmshelley nickmshelley mentioned this pull request Jun 1, 2016
@@ -67,10 +268,32 @@ public final class Connection {
/// Default: `false`.
///
/// - Returns: A new database connection.
public init(_ location: Location = .InMemory, readonly: Bool = false) throws {
public convenience init(_ location: Location = .InMemory, readonly: Bool = false, vfsName: String? = nil) throws {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the function docs above need to be updated to include the vfsName parameter.

@nickmshelley
Copy link
Collaborator

I opened #451 because this doesn't seem to be going anywhere. Let me know if there's a better way to get this through than opening a new PR.

@nickmshelley nickmshelley merged commit b7a0eb1 into stephencelis:master Jul 19, 2016
@kdubb
Copy link
Contributor Author

kdubb commented Jul 19, 2016

@nickmshelley My apologies I hadn't seen the resurrection of this PR until I was just notified about it being merged. All worked out it seems!

@kdubb kdubb deleted the connection_pool branch July 19, 2016 20:15
@nickmshelley
Copy link
Collaborator

@kdubb I hope so. Sorry if I stole any thunder.

@nickmshelley
Copy link
Collaborator

Also thanks for doing the bulk of the work @kdubb.

@stephencelis
Copy link
Owner

Thanks for shepherding this, @nickmshelley!

@jberkel jberkel mentioned this pull request Dec 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants