This implicit behaviour will happen before Identity gets a hold of anything, right? I'm not quite sure how it works, but our code ends up checking turbogears.identity.current.user quite a bit and if turbogears.identity.current.user was selected outside of the current transaction then 'turbogears.identity.current.user ==' won't match any User objects that are grabbed within that transaction.
First, I completely agree that a new transaction should be created to wrap ALL database activities during the request.
Unfortunately, I'm not certain how we can start a transaction before the Identity filter gets a crack at the request short of creating another filter that creates the transaction before starting to handle the request and rolls it back if it hasn't been committed by the time the request ends.
I know Kevin mentioned that we shouldn't worry about HOW to implement this yet. But the code that implements the Identity framework executes before the @expose decorated functions (which would be ONE place to put the transaction logic).
I don't remember if current is set as part of threadLocal (and if it is, does that mean it's persistent across requests?) or if it's just updated every time the user makes a request.
Yes, the current identity is stored in a threadLocal (in the SVN code, I've changed this in the code that needs to be committed), but it is updated on every request.
-- Jeff Watkins http://newburyportion.com/
