Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #225 (closed defect: fixed)

Opened 14 years ago

Last modified 12 years ago

Problem with new transaction support after revision 259

Reported by: jchu@… Owned by: anonymous
Priority: highest Milestone: 0.9
Component: TurboGears Version:
Severity: major Keywords:


First, let me explain how the all-requests-wrapped-in-transaction feature works currently:

1) Cherrypy gets a request 2) The first time a connection is requested from a hub, the connection is returned inside a transaction 3) When the exposed method is called, it's called through database.run_with_transaction. 4) At the end of the exposed method's execution, depending on the results of the call, database.rollback_all or database.commit_all is called (as well as database.end_all).

So far, everything seems fine.

Now, let me describe a situation. If you have a filter that accesses your model before the exposed method is called (like, say, the identity filter), a transaction will be created. Which is fine, as long as an exposed method is called.

If a filter is enabled and static files are being served up, a transaction will be created and never rolled back. In a single threaded environment, this is no big deal, but when you have multiple cherrypy threads, you could inherit a db connection that's within a transaction. Which means all sorts of weird database results.

Change History

comment:1 Changed 14 years ago by anonymous

  • Priority changed from normal to highest
  • Milestone set to 0.9

comment:2 Changed 14 years ago by kevin

  • Status changed from new to closed
  • Resolution set to fixed

I created a new filter that should help ensure that transactions are closed out at the end, regardless of whether you hit an exposed method. This is in [387].

Note: See TracTickets for help on using tickets.