On 11/16/05, Jonathan LaCour <[EMAIL PROTECTED]> 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 :)
I absolutely agree that transaction integrity is very important. I always work in transactions when I'm updating data. The issue is that SQLObject uses a separate cache for each transaction, but one cache when you're not working in a transaction. If you have lots of reads, you'll get lots of cache hits if you don't put those read operations in a transaction. > Assuming that most methods are "read only" is assuming things about > the application. That isn't safe to do, because there are many types > of applications. Some will be largely reading, others may be largely > update/create/delete, others may be an even split. You don't know > which is the primary case. What you *do* know is that read-only > methods can safely run in a transaction and that other methods *have > to* run in a transaction. If you run in a transaction in both cases, > everything is good. If you don't, then something can go wrong. > Seems like we have found our default, no? When coming up with defaults, we do have to make some assumption about what people are doing. I agree with you that transactions are the safer route, and there are many people who don't think about using transactions. (I wonder how many read/write databases still use MyISAM tables?) By turning them on by default, we automatically help people get a bit more consistency to their data. That sounds reasonable to me. As long as it's an easy bit to flip, I have no qualms about choosing what is ultimately a safer default. > > Now that i think about it, > > transactions are already maintained on the thread level so it should > > be fairly straightforward to keep reusing the same transaction. As > > Roman points out, there may be times where you want to use nested > > transactions (just make sure you're not using sqlite). So the trick is > > finding the best defaults and an easy way to diverge from the default. > > Fair enough, but you are *assuming* threads, which is another unsafe > assumption. We need to make sure to conform to the WSGI spec > regarding multi-process vs. multi-thread. People like me just aren't > going to be deploying their apps inside a multi-threaded server. It > should be easier in that case anyway, because then its one connection > per process :) So, you just use the processes' current transaction > instead of the thread's current transaction. Yes, I said thread because that's the default mode of operation for CherryPy, but working with a process-wide connection should work equally well. (Assuming we fix the caching problems you were seeing.) Kevin
