Re: Question about SERIALIZE transaction isolation

From: Roy Hann <specially_at_processed.almost.meat>
Date: Wed, 17 Jun 2009 11:46:49 -0500
Message-ID: <>

Brian Selzer wrote:

> "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.

I think you misintepret what I meant by "same transaction". I meant "the same" transaction B. My apologies for permitting the misreading.

> Updates that occur within a transaction
> /should/ be seen by subsequent queries within the same transaction.

Of course; but I didn't say otherwise.

Received on Wed Jun 17 2009 - 18:46:49 CEST

Original text of this message