> > Now, there are some obvious problems: > > You missed the real reason why this will never happen: it completely > kills any prospect of concurrent updates. If transaction A has > issued an update on some row, and gone and modified the relevant > aggregate cache entries, what happens when transaction B wants to > update another row? It has to wait for A to commit or not, so it > knows whether to believe A's changes to the aggregate cache entries.
I never claimed it was perfect, :) but it'd be is no worse than a table lock. For the types of applications that this would be of biggest use to, there would likely be more reads than writes and it wouldn't be as bad as one could imagine. A few examples: # No contension Transaction A begins Transaction A updates tab1 Transaction B begins Transaction B updates tab1 Transaction B commits Transaction A commits # contension Transaction A begins Transaction A updates tab1 Transaction B begins Transaction B updates tab1 Transaction A commits Transaction B commits This is just about the only case that I can see where there would be contension. In this case, transaction B would have to re-run its trigger serially. In the worse case scenario: Transaction A begins Transaction A updates tab1 Transaction B begins Transaction B updates tab1 Transaction A commits Transaction B selects Transaction B updates tab1 again Transaction B commits In my journals or books I haven't found any examples of a transaction based cache that'd work any better than this. It ain't perfect, but, AFAICT, it's as good as it's going to get. The only thing that I could think of that would add some efficiency in this case would be to have transaction B read trough the committed changes from a log file. After a threshold, it could be more efficient than having transaction B re-run its queries. Like I said, it ain't perfect, but what would be a better solution? ::shrug:: Even OODB's with stats agents have this problem (though their overhead for doing this kind of work is much much lower). -sc -- Sean Chittenden ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]