Re: Question about SERIALIZE transaction isolation
Date: Wed, 17 Jun 2009 23:27:11 -0700 (PDT)
On 17 Jun., 17:15, "Walter Mitty" <wami..._at_verizon.net> wrote:
> Going back some 15 to 25 years, Rdb/VMS implemented an interesting variation
> on the traditional locking scheme.
> In the default configuration, transactions that began ad READ-ONLY
> transactions were turned into SNAPSHOT transactions. Snaphot transactions
> could read everything that had been commited prior to the start of the
> snapshot transaction, but nothing else. That means that inserts committed
> after the snapshot are invisible to the snapshot, deletes commited after
> the snapshot are visible, and updates committed after the transaction have
> to deliver the before image of the data updated. Before images were stored
> in what I guess is multiversioning, in a special storage area for snapshot
> In the snapshot scheme as implemented by Rdb/VMS Txn B is treated as BEFORE
> Txn A, even though Txn A started first. It therefore will not see the insert
> doen by Txn A before Txn A committs, and even after Txn A commits. If
> snapshotting has been disbled by the DBA or if the transaction is started as
> read write, even though it's not going to write anything,
> Txn B will block when it tried to read data altered by Txn A, and wait for
> A to complete.
> The Rdb/VMS implementation may not be of any interest to you in terms of the
> engine you are building, but it's interesting to note that this question
> has been asked and anaswered before. Hopefully, some of the literature
> concerning building database systems has captured whatever insights of
> value, if any, were captured by the Rdb engineers way back when.
thanks for the reply.
The SNAPSHOT is interesting for two reasons:
- it's very easy for me to be implement
- i read about it this morning when reading a paper about future OLTP development trends. A paragraph caught my attention, it writes about "relaxed" transactional models (ACI without D etc): """For example, the widespread adoption of snapshot isolation (which is non-transactional) suggests that many users are willing to trade transactional semantics for performance (in this case, due to the elimination of read locks)."""
In my case i don't hold any locks, so i don't have performance penalties. But after reading your reply i understand that SNAPSHOT isolation improved the locking in more traditional DBMS engines.
Anyway - i decided yesterday to pick READ_COMMITTED as my default isolation level. That's the only level i implement (for now) and i really want to have my first release this month, that's why i'm going for the cheapest solution :) (other isolation levels will follow later, they don't have such a high priority for me).
But before i do that, i'll look for good literature about this topic. Recommendations are welcome.
Christoph Received on Thu Jun 18 2009 - 08:27:11 CEST