On Dec 3, 6:49 am, Chuck Remes <[email protected]> wrote:
> On Dec 2, 2009, at 2:32 PM, Jeremy Evans wrote:
> > If you fix those issues and add documentation and specs, I'll include
> > this as long as it passes the test suite.
>
> I just forked the repository. I'll send you a pull request after I get  
> this implemented and documented.

Great! Thanks for your help.

> > Your post got me thinking about changes to ConnectionPool#disconnect:
>
> > 1) Start accepting an options hash, for a :servers option, for only
> > disconnecting those servers.
>
> If you provide a Database#remove_server then this suggestion would be  
> "sugar" for calling #delete_server and then #add_server with new  
> options. I like it.

remove_server would have issues unless you ran it in synchronous mode,
because you'd need to wait for all active connections to complete
before removing the necessary hash keys.

I suppose you could handle it asynchronously by having the flag set on
the connecting threads (nothing/disconnect/
disconnect_and_remove_server).

And now that I think about it, a simple flag implementation is likely
to be problematic anyway, since a single thread can appear multiple
times in the connection pool (it's only unique per server).

> > 2) Have it start checking allocated connections, marking the threads
> > with a flag.  When the connection is released, the flag is checked,
> > and if present, instead of the connection being returned to the pool,
> > it is disconnected.  This would allow calling disconnect even when
> > there are active connections, knowing that any active connections will
> > be disconnected as soon as they are finished.  This would also allow
> > add_server to change existing servers, by disconnecting, and having
> > new connections go to the new server.
>
> I would suggest adding this behavior as optional parameters to  
> Database#disconnect.
>
> :remove_all => boolean
> Flag all connections to be disconnected and removed from the pool
>
> :async => boolean
> When true, perform this operation asynchronously. When false, block  
> until all connections are removed.

I'd change this option to :sync.  Async is the current behavior, if
you want synchronous behavior, you should need to specify it.  Unless
you think synchronous behavior is the better default and worth
breaking backwards compatibility for.

Lots of good ideas here, I'm sure we can get this done this month in
time for Sequel 3.8.0.

Jeremy

--

You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sequel-talk?hl=en.


Reply via email to