Sequel is great
The ConnectionPool classes were refactored from 2 separate classes to a 5 class hierarchy, with one main class and 4 subclasses, one for each combination of sharding and threading.
The primary reason for this refactoring is to make it so that the user doesn’t have to pay a performance penalty for sharding if they aren’t using it. A connection pool that supports sharding is automatically used if the :servers option is used when setting up the database connection.
In addition, the default connection pool no longer contains the code to schedule future disconnections of currently allocated connections. The sharded connection pool must be used if that feature is desired.
The unsharded connection pools are about 25-30% faster than the sharded versions.
An optimistic_locking plugin was added to Sequel::Model. This plugin implements a simple database-independent locking mechanism to ensure that concurrent updates do not override changes:
In addition, the default connection pool no longer contains the code to schedule future disconnections of currently allocated connections. The sharded connection pool must be used if that feature is desired.
