On Mar 28, 2008, at 11:54 PM, Graham Dumpleton wrote:
> > > > On Mar 29, 11:02 am, Michael Bayer <[EMAIL PROTECTED]> wrote: >> On Mar 28, 2008, at 7:56 PM, john spurling wrote: >> >>> I added debugging to get id(session) and len(list(session)). The >>> session id is unique every time, and len(list(session)) is 0. I also >>> called session.clear() before using it. Unfortunately, the caching >>> behavior persists. >> >>> Any other suggestions? Thank you very much for your time and help! >> >> if its zero, then the Session isnt caching. Something is going on >> HTTP/process-wise. > > Could it be that because Apache is a multi process web server (on > UNIX), that OP is getting confused through subsequent requests > actually hitting a different process. > > That said, sqlalchemy as I understood it was meant to deal with that, > ie., change made from one process should be reflected in another > process straight away upon a new query, ie., cached data should be > replaced. Is it possible that what ever insures that has been > disabled. > > OP should perhaps print out os.getpid() so they know which process is > handling the request each time. This may help to explain what is going > on. the only "cache-like" thing SA has is the session...and in this case we are starting from an empty session, so no caching is taking place. my next idea is that the UPDATE you're issuing is not being committed within its transaction so is not visible to other connections. Although thats unusual for MySQL since its commandline is usually in autocommit mode. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
