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