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.
