SOLVED: I mentioned in my first post that I was using the XMLRPCController. Well, in my BaseController that inherits from WSGIController, I properly call Session.remove() at the end of each request, which gets rid of the session completely, and each request starts with a new fresh session. Well, since I was using XMLRPCController, this Session.remove() never got called because my BaseController was nowhere to be found in the inheritance chain.
So the solution seems to be to implement as BaseXMLRPCController (XMLRPCController) and override __call__ so that it always calls Session.remove() at the end of each request. After looking at which thread each function was running on I noticed a pattern. Each web request would generate a new thread up to about 9 threads, then the next request would reuse thread #1 from the threadpool. Because Session.remove() was never being called, thread #1 still had a Session attached to it, with the old state of the table. The function that got handed this old thread that still had the Session hanging around would have stale data. On Feb 17, 12:30 pm, Bryan <[email protected]> wrote: > MySQL. > > According to the "Lifespan of a Contextual Session" section > @http://www.sqlalchemy.org/docs/05/session.html#contextual-thread-loca... > Each web request should be getting a new session. That makes sense, I > am calling Session.remove() at the end of the WSGIController.__call__ > () > > I am going to do some more tests. This is confusing me. > > On Feb 17, 12:17 pm, Brennan Todd <[email protected]> wrote: > > > Which database are we talking about here? > > > On Tue, Feb 17, 2009 at 2:13 PM, Bryan <[email protected]> wrote: > > > > It is called in a separate web request. I am using scoped_session, so > > > if the 2 requests were on the same thread, they should use the same > > > session. I don't think the 2 requests are on the same thread. > > > Printing threading.currentThread() from login() gives me <Thread > > > (worker 0, started)> and anotherFunction() prints <Thread(worker 1, > > > started)> > > > > So lets assume they are not using the same session for the sake of > > > argument. The anotherFunction() would be getting a new fresh session > > > correct? And that session should see the database table as it is, not > > > as it was before login() was called. > > > > If we assume that they are sharing the same session, then > > > anotherFunction() would see the database table the same was login > > > does, right? > > > > Neither of these situations is happening. > > > * Table State 1 --> login() --> Table state 2 > > > login() can see Table state 2, but any other function in my controller > > > that is called after login() still sees Table state 1. > > > > On Feb 17, 11:54 am, Paweł Stradomski <[email protected]> wrote: > > > > W liście Bryan z dnia wtorek, 17 lutego 2009: > > > > > > 1. Client calls login(), a new row is inserted in the token table. > > > > > 2. Client calls anotherFunction and the new row is not visible inside > > > > > that function > > > > > 3. If I place a Session.commit() in anotherFunction, then I can see > > > > > the row > > > > > Is anotherFunction called in another session, which has started its own > > > > transaction earlier with SERIALIZABLE isolation? If so, then the row > > > might > > > > not be visible as it would be a phantom. > > > > > -- > > > > Paweł Stradomski > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
