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.
