TG 2.0.x transaction rollback/doom

17 views
Skip to first unread message

ozwyzard

unread,
Sep 6, 2010, 8:32:45 PM9/6/10
to TurboGears
Hello,

I attempted trial and error (and poked around some code), but am not
able to figure out the intended method of doing transactions in a TG 2
application.

import transaction

def parent():
try:
urec = User(name='test', ...)
DBSession.add(urec)
# transaction.doom() works if placed here before the query
newrec = DBSession.query(User).filter(User.name='test', ...
blah)
child_routine_that_does_dependent_DB_ops() # DB op works but
routine raises an exception for TESTING
except Exception, e:
transaction.doom() # Does not remove the urec record from DB

What is the correct method for doing transaction rollbacks? Does the
rollback not occur after a successful query? Do I need to modify some
config item?

(I tried setting DBSession.autoflush = False,
transaction.manager.abort(), DBSession.rollback(), but none of these
work).

Thanks!

Michael Pedersen

unread,
Sep 7, 2010, 1:26:50 AM9/7/10
to turbo...@googlegroups.com
This actually took me a little bit to spot. I can't give a definitive answer, but I can provide some explanation.

On your line in the try block where you say that "transaction.doom() works if placed here before the query", that's where you give the real clue. Somehow, in your setup, a commit is being done before that query gets executed. Because of that, you are now in a new transaction when the child routine raises its own exception. As you're in a new transaction, you no longer can rollback the DBSession.add(urec) that was done.

For this particular issue, I have to strongly recommend contacting the SQLAlchemy group. Somehow, a commit is being done, and I'm not capable (personally) of figuring out why. Since SQLAlchemy is doing the commit, I have to recommend asking them for help debugging why the commit is occurring.


--
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbo...@googlegroups.com.
To unsubscribe from this group, send email to turbogears+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.




--
Michael J. Pedersen
My IM IDs: Jabber/pede...@icelus.tzo.com, ICQ/103345809, AIM/pedermj022171
          Yahoo/pedermj2002, MSN/pederm...@hotmail.com

ozwyzard

unread,
Sep 7, 2010, 1:49:13 PM9/7/10
to TurboGears
Thanks for the response. That (commit) is my suspicion as well. So,
I was wondering if there is any TG configuration that is driving
this. I'll try to dig and see if there are any debug settings to show
sqlalchemy DB transactions. If I am still stumped I will try and post
to the sqlalchemy group (as you suggest).

Thanks.
> > turbogears+...@googlegroups.com<turbogears%2Bunsu...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/turbogears?hl=en.
>
> --
> Michael J. Pedersen
> My IM IDs: Jabber/peder...@icelus.tzo.com, ICQ/103345809, AIM/pedermj022171
>           Yahoo/pedermj2002, MSN/pedermj022...@hotmail.com

ozwyzard

unread,
Sep 7, 2010, 1:49:29 PM9/7/10
to TurboGears
Thanks for the response. That (commit) is my suspicion as well. So,
I was wondering if there is any TG configuration that is driving
this. I'll try to dig and see if there are any debug settings to show
sqlalchemy DB transactions. If I am still stumped I will try and post
to the sqlalchemy group (as you suggest).

Thanks.

On Sep 7, 1:26 am, Michael Pedersen <m.peder...@icelus.org> wrote:
> > turbogears+...@googlegroups.com<turbogears%2Bunsu...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/turbogears?hl=en.
>
> --
> Michael J. Pedersen

Michael Pedersen

unread,
Sep 7, 2010, 2:06:41 PM9/7/10
to turbo...@googlegroups.com
I can safely say that the default configuration does not do any sort of autocommit. I tried it out, and used exactly what you made in your sample code. Without any sort of manual commit from me, the data was not being saved to the database.

To unsubscribe from this group, send email to turbogears+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.




--
Michael J. Pedersen

ozwyzard

unread,
Sep 9, 2010, 4:50:28 PM9/9/10
to TurboGears

ozwyzard

unread,
Sep 13, 2010, 10:13:20 PM9/13/10
to TurboGears
I bumped up the [logger_sqlalchemy] to DEBUG and noted that COMMIT is
not called in the scenario under discussion. I also confirmed that
the "COMMIT" string does get logged when appropriate.

The implication being that "COMMIT" string does appear in logger when
appropriate, and in the current scenario "COMMIT" is not appearing,
indicating that there is no COMMIT occurring, yet the transaction is
not rolling back.

If I come across further info, I will update this thread. If anyone
else any other suggestion, kindly post.

Thanks.

On Sep 9, 4:50 pm, ozwyzard <ozwyz...@gmail.com> wrote:
> I have posted a query on the sqlalchemy group.
>
> http://groups.google.com/group/sqlalchemy/browse_thread/thread/9b7c83...
Reply all
Reply to author
Forward
0 new messages