threadConnection is thread-aware; but if you are running single- threaded it doesn't hurt anything to use it.
So, it should be safe to use your "run_in_transaction" routine then? I will probably make a decorator out of it, but shouldn't this be part of TurboGears?
It seems to me that transactions should be on by default, and automatically occur in the transaction-per-request model with automatic commit and rollback. Why isn't this the case already? Would it be hard to do? Would it work in both thread-per-request and process-per-request models? This seems like a basic requirement for "web frameworks."
OTOH, caching with multiple processes and SQLObject can get a little hairy. I can't give a quick answer about that, because I've been putting off thinking through the implications for some time :(
Agreed. I have caching disabled right now, and I am seeing some odd behavior where things don't seem to "stick" quite properly. Specifically, I update a model object, and the interface will randomly reflect the change, or not, as I refresh.
I think its either an issue with how I am handling transactions (which is why I asked in the first place), or an issue with SQLObject still caching even though I tell it not to (all I did was set "? cache=0" at the end of my sqlobject.dburi property in my configuration files).
Any ideas on this would be appreciated :) -- Jonathan
