Re: Question about SERIALIZE transaction isolation

On 17 Jun., 17:15, "Walter Mitty" <wami..._at_verizon.net> wrote:
> Cristoph,
>
> 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
> data.
>
> 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.

Hi Walter,

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.

Regards
Christoph Received on Thu Jun 18 2009 - 08:27:11 CEST