Re: Question about SERIALIZE transaction isolation

From: Brian Selzer <>
Date: Wed, 17 Jun 2009 12:35:30 -0400
Message-ID: <iX8_l.29$>

"Roy Hann" <specially_at_processed.almost.meat> wrote in message
> Christoph Rupp wrote:
>> Hi,
>> i'm nearly ready for my first release of my new concurrent, multi-
>> threaded, ACID transactional, logical idempotent logging, lock-free
>> database engine (key/value storage).
>> OK, enough buzzwords for today :)
>> Some of you were kind enough to help me a couple of times with my
>> questions. This one is about the behaviour of a read-only transaction
>> in the SERIALIZE isolation level.
>> TXN A:
>> INSERT (a, b)
>> TXN B:
>> FIND (a)
>> Does the lookup of an un-committed item return KEY_NOT_FOUND or does
>> it create a transaction conflict?
> The key shouldn't be found in transaction B, and to maintain
> serializable isolation it should never be found even by a future query
> in the same transaction.

This is not what is intended by the serializable transaction isolation level. A transaction executing under the serializable transaction isolation level requires that every update by /other transactions/ be blocked if it might affect query results. Updates that occur within a transaction /should/ be seen by subsequent queries within the same transaction.

> I have no idea what a "transaction conflict"
> is but it sounds like an error. The point of serializable isolation is
> to create a realistic illusion that you have the database for your
> sole use. Random errors caused by the actions of other users would
> spoil that illusion. If you don't want to wait, you'll have to keep
> track of key values that are added while transaction B is in progress so
> you can make sure you exclude them from the results of that transaction.
> --
> Roy
Received on Wed Jun 17 2009 - 18:35:30 CEST

Original text of this message