yeah, the example in the docs was originally like the second example that you have. what was happening in practice was the actual flush operation occurs within the commit(), which has its own try/except block. when the flush inside the commit() fails, it catches the error, rolls back the transaction, and then raises the error. if you put the commit() inside your own try/except, then you catch the error and say trans.rollback(), *that* was failing because you couldnt roll back twice, and raising its own exception so you couldnt see the original error. now, that can be fixed (or maybe it already has been) so that calling rollback() a second time just does nothing.
so yeah, in both cases the database transaction is definitely rolled back, and the unit of work is designed so that it doesnt change any of its internal state until the commit succeeds, so its *safe* in both methods. looking at it now, method #2, which is what i had originally, might be better since it gives you the option to do something extra if your commit (and flush) fails. I just went and retraced what i was looking at when i made that decision, so i think #2 might be better. I use Spring at the day job, and i think i saw this doc: http://static.springframework.org/spring/docs/1.2.x/reference/ transaction.html#d0e5671 which shows method #1. but going back to hibernate shows method #2: http://www.hibernate.org/hib_docs/v3/reference/en/html/ transactions.html#transactions-demarcation-nonmanaged funny how even those guys cant agree :) On Sep 20, 2006, at 10:29 AM, dmiller wrote: > The documentation for SessionTransaction has a short example to show > how it should be used (http://www.sqlalchemy.org/docs/ > unitofwork.myt#unitofwork_transaction): > > > sess = create_session() > trans = sess.create_transaction() > try: > item1 = sess.query(Item).get(1) > item2 = sess.query(Item).get(2) > item1.foo = 'bar' > item2.bar = 'foo' > except: > trans.rollback() > raise > trans.commit() > > > What happens to the transaction if the commit fails? Is it rolled > back or is it left hanging in an uncommitted state? I personally have > the urge to structure it like this: > > > sess = create_session() > trans = sess.create_transaction() > try: > item1 = sess.query(Item).get(1) > item2 = sess.query(Item).get(2) > item1.foo = 'bar' > item2.bar = 'foo' > trans.commit() > except: > trans.rollback() > raise > > > That way the transaction is always rolled back in the event of an > error, even when the commit fails. In fact, that's the way it's done > within ComposedSQLEngine.transaction(), although that method is not > working with SessionTransactions. Is there a difference between the > two approaches? > Thanks. > > ~ Daniel > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Sqlalchemy-users mailing list > Sqlalchemy-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
