On 18 May 2002, Titus Brown said: > It sounds to me like the best way to integrate all of this into a > transaction-oriented database is to have the save_changes take an > in-memory representation and map them into the database, and then > do a commit immediately. With ZODB at least, there's no need for your application to worry about mapping in-memory objects to database objects -- ZODB does it for you. Currently, the core of our persistent session manager class is this: class MXSessionManager: [...] def abort (self): get_transaction().abort() def commit (self): get_transaction().commit() With the latest changes to Quixote's session management API, I think this will have to change to: def forget_changes (self, session): get_transaction().abort() def save_changes (self, session): get_transaction().commit() ...which is why I'm not too fussed about making these changes. > I'm using a home-grown object <--> database > mapping system that (like ZODB?) automagically transmits the changes > to the database, modulo a commit; does this change in session management > protocol mean that for this sort of database system, you'd either have > to decouple the session from the database-linked object until > save_changes() is called, or keep a separate transaction handle for each > session? If your home-grown OODB works like ZODB, which is what it sounds like to me, then I don't think you have anything to worry about. In the course of processing one request, you should only modify one session -- the session identified by that request's session cookie. (Yes, you can always get your hands on the global SessionManager carried around by your publisher and go grubbing through other sessions. That's your problem though, and if you do that sort of thing, it's up to you to save the sessions that you so modify.) Thus, commiting "the current transaction" *should* just save the changes to the one session that you (may) have changed in the course of processing the current request. Clear as mud? Greg