We're using SA 0.4.4. We're creating non-threadlocal sessions that are bound to an engine at session factory creation time. Any ideas for why even after closing one session and creating a new session with the session factory that we're seeing old data? If we do an explicit commit or rollback, then we start seeing the new data in subsequently created sessions. I even tried doing refresh() and expire() calls on the object before closing and re-creating the session, but we still saw the old data.
On May 27, 6:04 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > On May 27, 2008, at 5:35 PM, TP wrote: > > > > > > > From reading the docs, it sounds like calling .close() on a session > > implicitly does a .rollback(): > > > "When the Session is closed, it remains attached, but clears all of > > its contents and releases any ongoing transactional resources, > > including rolling back any remaining transactional state. The Session > > can then be used again." > > > But, it looks like this may not be the case? > > > I have an application that reads data from a MySQL db using InnoDB > > tables and the session is set to transactional. I believe this > > defaults me into MySQL's "repeatable read" consistency level. If I > > select some data, .clear()/.close() the session, change the data from > > another connection and then re-read the data using the original > > session I get the old data. If I do a commit() I can then see the new > > data. > > > This makes me think that .close() is not doing a rollback so MySQL > > keeps returning the same data for every select regardless of whether > > it has changed in the DB. Or am I missing something else? > > what close() does is release any checked-out connection resources > which the Session might have used. The connection pool by default > issues rollback() on connections when they are returned, so thats the > rollback which happens; the connection is gone from the Session in any > case. > > There is also a behavior in 0.4 which is gone in 0.5 which is that the > connection pool is returning connections from a threadlocal registry. > So if you have two sessions in the same thread, they're going to share > that connection. In 0.4 this can be turned off by sending > "pool_threadlocal=False" to create_engine(). > > Otherwise, it sounds like you are binding your Session directly to a > Connection. In that case you'd just issue rollback() on that session > which will issue the rollback() on the connection, and then an > expire_all() or clear(). > > If you're just starting to use SA, I'd strongly recommend using the > 0.5 trunk which will start having alpha releases soon. The > transactional interaction has been greatly improved, and rollback() > will revert the state of the session fully using attribute expiry as > well as reverting "pending" and "deleted" objects to "transient" and > "persistent" respectively. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
