Jonathan LaCour wrote:
For the potentially many methods that are just reading data, you don't
really want a transaction, and decorators are a nice way to configure
where you want the transaction.
I fail to see the harm in starting a transaction for read-only
methods? What's the big deal? It seems like transactional integrity
is pretty important, and automating it would be really nice :)
Well, just as a data point, in Zope (where you always get a transaction
whether you like it or not, and aren't given any control over how it
works) this has kicked me in the ass before. It's also usually nice.
But the ass-kicking really sucks. One of Zope's features is that if you
get a conflict error, it'll re-run the request for you, essentially
creating a situation where when contention gets high you don't require
the user to hit submit over and over, you hit submit over and over *for*
the user. Lovely.
However, conflict errors are inevitable when you start running
everything in transactions, and that's something that should probably be
taken into account.
That said, there certainly is a genuine appeal to putting everything in
transactions.
The only other alternative that I can think of, is to automatically
realize when you need to run inside a transaction by having SQLObject
start one automatically when a create, update, or delete occurs and
then have TurboGears commit or rollback any open transactions at the
conclusion of a request depending on whether or not an "exceptional"
Exception occurred.
SQLObject can't current do this, but I don't think this would be too
difficult. Basically you'd create another Transaction subclass, and it
would watch for updating methods, and would only start using its own
transactional connection once one had gone by. I think this could
reduce the likelihood of contention quite a bit, so long as you aren't
too concerned about absolutely isolated transactions. I.e., your first
select may not be consistent with your second select, but if you run
that in a transaction (with the right isolation) it would be.
There are some open caching issues with transactions as well, that
require some thinking about what has to be expired when. And, really,
transactions could probably make more use of caching than they currently do.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
