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: <JN2dncvD8uZkgKTXnZ2dnUVZ8jydnZ2d_at_pipex.net>


Brian Selzer wrote:

>
> "Roy Hann" <specially_at_processed.almost.meat> wrote in message
> news:ef6dncCufqMTcqXXnZ2dnUVZ8k6dnZ2d_at_pipex.net...
>> 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:
>>> BEGIN
>>> INSERT (a, b)
>>>
>>> TXN B:
>>> BEGIN
>>> 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.

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

Original text of this message