-> 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.

Right -- but in that case, for every open session, you have a separate
transaction handle to the database.

-> > 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?

Gotcha.  I guess I'm just worrying again about the multiple-connections
issue (== threading, basically) which I should just stop worrying about ;).

--titus