Re: Question about SERIALIZE transaction isolation

From: Christoph Rupp <>
Date: Wed, 17 Jun 2009 06:59:59 -0700 (PDT)
Message-ID: <>


thanks for your reply.

On 17 Jun., 15:28, Roy Hann <specia..._at_processed.almost.meat> wrote:
> 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.  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.

When i read that, i realize that i actually implemented READ_COMMITTED instead of SERIALIZABLE :(

INSERT (a, b)

                           BEGIN TXN B
                           FIND (a) -> error/block
                           FIND (a) -> found!
                           COMMIT B

Now i have two choices: either use READ_COMMITTED as my default isolation level or fix the SERIALIZABLE isolation level. A quick search shows that MSSQL uses READ_COMMITTED as the default level, and others (Oracle, SAPDB) as well. So i guess i do that, too.

Christoph Received on Wed Jun 17 2009 - 15:59:59 CEST

Original text of this message