Re: computational model of transactions

From: Marshall <marshall.spight_at_gmail.com>
Date: 1 Aug 2006 17:19:11 -0700
Message-ID: <1154477950.942589.175470@p79g2000cwp.googlegroups.com>

Bob Badour wrote:

> Instead of committing after every transaction the batches committed
> after every n transactions. Now, I realize that makes them all part of
> the same transaction in terms of begin transaction/commit transaction,
> but in terms of serializability, this introduces no risk.

Whoops! You just made me think of something I hadn't thought of earlier: composability and nested transactions. If we have "small" transactions t1 and t2, and transaction T which "contains" t1 and t2, then we need to ensure that executing t1, t2 standalone produces the same results as executing t1 and t2 inside T. Which means that my idea of "transaction can only see the state at transaction-start-time" needs to be the exact current transaction, not the nesting transaction. Which I'll have to think about.

The merging-multiple-transactions objection is interesting but doesn't kill the idea (at least not yet,) because it's a performance optimization based on a specific implementation, which is in turn based on the standard model. It would have to be established that the same performance effect applied in the new model, and I'm not sure it does.

Marshall Received on Tue Aug 01 2006 - 19:19:11 CDT