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. For our application, in its current development stage, I just wrote a filter that calls database.end_all onStartResource, but this isn't the final solution. I've submit a ticket with the same info in it: http://trac.turbogears.org/turbogears/ticket/225 I realize that implementing the whole thing as a filter isn't the solution (what if other filters are called before ours?). I hate to say I told you so, but I knew something would go wrong with this ;) Thoughts? Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
pgpAIyJadIUdZ.pgp
Description: PGP signature
