the stack trace points to pool.py (I will get the exact stack trace as I am away from my box currently)
>> does the conflict occur frequently and easily with just a little bit of concurrency or is it something that only happens under very high load conditions ? this is happening primarily in a use case wherein the logic does some processing (this includes accessing many relations - i believe many lazy loaders fire here). since this use case generates some csv data it takes about 6-7 secs depending on the data set so when other requests comes in while other is in progress we encounter the 2014 error. however as mentioned earlier when i use threadlocal queue pool it just vanishes and no matter how many requests i send after that it just works fine. On 7/20/07, Michael Bayer <[EMAIL PROTECTED]> wrote: > > > perhaps the nature of the conflict is different, then. are you able > to observe what stack traces or at least approximately what operations > are taking place when the conflict occurs ? does the conflict occur > frequently and easily with just a little bit of concurrency or is it > something that only happens under very high load conditions ? > > > > > > -- Cheers, - A --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
