Re: Question about SERIALIZE transaction isolation
- From: Christoph Rupp <cruppstahl@xxxxxxxxx>
- Date: Wed, 17 Jun 2009 06:59:59 -0700 (PDT)
Roy,
thanks for your reply.
On 17 Jun., 15:28, Roy Hann <specia...@xxxxxxxxxxxxxxxxxxxxx> 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.
Regards
Christoph
.
- References:
- Question about SERIALIZE transaction isolation
- From: Christoph Rupp
- Re: Question about SERIALIZE transaction isolation
- From: Roy Hann
- Question about SERIALIZE transaction isolation
- Prev by Date: Re: Question about SERIALIZE transaction isolation
- Next by Date: AT&T Usenet Netnews Service Shutting Down
- Previous by thread: Re: Question about SERIALIZE transaction isolation
- Next by thread: Re: Question about SERIALIZE transaction isolation
- Index(es):
Relevant Pages
|