Thanks for your quick answer, Michael, that's really helpful. Sorry for the confusion surrounding subtransactions vs. SAVEPOINTs — I am indeed using subtransactions… just clearly haven't got the lingo down yet ;)
Looking at my code now, I'm not too sure why I felt the need to call close() at all as you said "within arbitrary points of the callstack". The way I'm dealing with the boilerplate issue is with a context manager for transactions (with transaction(session): ...), so I'm guaranteed that either commit() or rollback() gets called on each subtransaction. I don't know as that's the best way to do it, but it does eliminate a lot of try...except...else's since I do need the explicit subtransaction stuff. In any case, thanks for clearing that up for me, and it's good to know about those accessors. On Oct 14, 3:18 pm, "Michael Bayer" <[email protected]> wrote: > Oliver Beattie wrote: > > > Hi All, > > > I'm just wondering what happens if I were to call session.close() > > whilst inside a subtransaction? Would it indeed close the session and > > abort all of the "parent transactions" or would it do nothing? > > > Looking at the code (and I haven't looked at it in any great detail, > > sorry) I imagine that it does indeed abort all parent transactions. If > > so, is there any way to tell whether the session is "in a > > subtransaction state" or not, so I could only call close() if it is > > the "root"? > > > Sorry if this is a bit confusing or if I'm being horrendously > > ignorant :) > > close() removes all transactional markers present. The connection is > returned to the pool and a rollback() occurs on it which will release any > state left on the connection. > > If you have an application that is making explicit usage of > subtransactions, that is session.begin(allow_subtransactions=True), that > would imply a nesting of functionality within methods which each issue an > explicit begin/commit pair (note that this is different from a "nested" > transaction, which uses SAVEPOINT. Since you said "subtransactions" I'm > going with that concept). In the first place, such a usage pattern is > extremely rare, even though SQLA makes use of it internally - its a lot > easier to construct an application where there is a single point of > begin/commit for a particular session, instead of having that kind of > boilerplate in multiple places. Secondly, if you are in fact using that > sort of pattern, I wouldn't try to call close() within arbitrary points of > the callstack. Ensuring that rollback() or commit() is called at the end > of each block will ensure that transactional/connection state is released > when the full nest of operations complete. > > Session has an "is_active" accessor which will indicate if a transaction > is present. to tell if its a "subtransation" you'd need to say > "sess.transaction and sess.transaction.is_active and > sess.transaction._parent". > > > > > > > —Oliver --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" 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/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
