I've got some thoughts on this but time is scant today to come up with what I'm thinking. Basically doing this totally with the pool itself. I'll try to get some time to work on it ....
On Nov 7, 2011, at 3:32 AM, Tarek Ziadé wrote: > Here's my v3, with a mechanism to refresh the shared pool when an > engine rebuilds it via dispose > > http://tarek.pastebin.mozilla.org/1376367 > > It also have a few thread locks to try to make it thread-safe. > > I've written some tests with hundreds of threads and it seems to work > fine, but I don't really know if there are other places where I should > do something. > > > On Fri, Nov 4, 2011 at 4:45 PM, Michael Bayer <mike...@zzzcomputing.com> > wrote: >> >> On Nov 4, 2011, at 3:41 AM, Tarek Ziadé wrote: >> >>> On Fri, Nov 4, 2011 at 10:33 AM, Tarek Ziadé <ziade.ta...@gmail.com> wrote: >>> ... >>>> Will try and come back ;) >>> >>> Hello, I am back \o/ >>> >>> Here's my v2: http://tarek.pastebin.mozilla.org/1373520 >>> >>> This time I have created a custom Strategy and Engine classes, and the >>> get_engine() function takes care of instanciating a pool for the >>> server if needed, and an engine instance per sqlurl, using that pool/ >>> >>> I have used Engine.contextual_connect for the schema switching, and >>> Engine.execute has our custom execution things. >>> >>> I guess this is much cleaner since anyone can use create_engine() with >>> my new strategy. >>> >>> The only assumption I am making is that there's a shared pool on the same >>> host. >>> >>> >>> Does this look better ? >>> >>> Thanks for your help so far >> >> OK this is clearer to me. So you're really trying to get it so that any >> number of create_engine() calls all use the same pool based on hostname, OK. >> >> If i have time today I might want to try paring this down a lot more. >> Also not sure why you need the "disconnect check" stuff in execute() , SQLA >> has that stuff built in. But it does raise an important point that the >> mechanism by which we dispose the pool when a disconnect is detected >> probably should be different here, since the disposal is per-engine, just >> gives itself a new pool. The other engines will still point to the old, >> disposed pool, probably causing some kind of pileup. >> >> >> >> >> >> >>> >>> Cheers >>> Tarek >>> >>> -- >>> Tarek Ziadé | http://ziade.org >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "sqlalchemy" group. >>> To post to this group, send email to sqlalchemy@googlegroups.com. >>> To unsubscribe from this group, send email to >>> sqlalchemy+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/sqlalchemy?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sqlalchemy" group. >> To post to this group, send email to sqlalchemy@googlegroups.com. >> To unsubscribe from this group, send email to >> sqlalchemy+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/sqlalchemy?hl=en. >> >> > > > > -- > Tarek Ziadé | http://ziade.org > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to sqlalchemy@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
