Re: Question about SERIALIZE transaction isolation
Date: Wed, 17 Jun 2009 06:59:59 -0700 (PDT)
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 :(
BEGIN TXN A
INSERT (a, b)
BEGIN TXN B FIND (a) -> error/block COMMIT A 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