On 11/2/05, Jonathan LaCour <[EMAIL PROTECTED]> wrote: > > > 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?
The "hub" object that you have in your model.py has begin, commit, rollback and end methods for working with transactions. > 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." There was a discussion about this a few weeks back. You don't necessarily *always* want to be in a transaction, because when you switch to a transaction you lose your cache. (Though it sounds like the cache was an issue in your multiprocess environment anyhow). Enabling a transaction-per-request model should be doable and would be desirable. There's even a ticket on this: http://trac.turbogears.org/turbogears/ticket/80 > > 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). When you start using an SQLObject Transaction, you have a cache specific to that transaction (if memory serves). So, if you're always in a new transaction, you should always have a cache just for that request. that'd be the theory, at least. Kevin
