The behavior you want will happen if you set the transaction isolation level
to serializable. Your appserver will work like the best of them. The
problem is in the database. While they all support serializable, it
generally provides a drag on performance. I cannot quantify it, but I
expect it to be sizable.
Cheers
-----Original Message-----
From: Lawrence Bruhmuller
To: [EMAIL PROTECTED]
Sent: 6/30/01 12:49 AM
Subject: Re: To scale or to be correct: that is the question
Why will setting Serializable necessarily kill performance? Reading
some messages further on down this thread, it seems that since there are
no read locks, the behavior that I wanted from the example I gave will
happen if I have Serializable set in Oracle.
Assuming that I don't want updates to happen right on top of each other
after stale selects in the same TX, isn't this the way to go? Doesn't
this obviate the need for the update verification at the app layer that
everyone has been talking about?
Or is there some additional overhead to doing this checking for TX
integrity that I don't know about that will slow even read performance
to a crawl?
Just want to be clear, appreciate your help.
- Lawrence Bruhmuller
On Fri, 29 Jun 2001 14:31:43 -0400, Jay Walters <[EMAIL PROTECTED]>
wrote:
>Much more performant to do the optimistic locking with read committed
>isolation. Serializable will kill performance.
>
>-----Original Message-----
>From: Tinou Bao [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 29, 2001 1:54 PM
>To: [EMAIL PROTECTED]
>Subject: Re: To scale or to be correct: that is the question
>
>
>Isn't this what transaction isolation levels are for? If you do a set
>transaction isolation level serializable Oracle will give you a can't
serial
>exception. If you need higher performance then you can keep the
default
>read committed but have to accept that data consistency will be
>comprised...so my question then is it better to set transaction
isolation
>level serializable or to do a verified update with the where clause...
>
>--
>Tinou Bao
>www.baosys.com
>
>
>----- Original Message -----
>From: "Lawrence Bruhmuller" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Friday, June 29, 2001 1:09 PM
>Subject: Re: [EJB-INT] To scale or to be correct: that is the question
>
>
>> Cedric, I have been reading this whole thread and I feel that the
>disconnect boils down to this:
>>
>> You are saying that most DBs, such as Oracle, will not allow
concurrent
>updates to happen, that would otherwise corrupt the database (someone
>earlier kept mentioning "corrupting" the DB).
>>
>> However, maybe what we mean as data corruption are two different
things.
>What I want to avoid is an update of data that has been updated since
the
>read that led to doing the second update in the first place (in one
TX).
>>
>> Check out this example. What you have said in this thread would lead
me
>to believe that an exception would occur, but I have verified that in
effect
>an exception does NOT occur. Perhaps this example is not what the kind
of
>scenario to which you were referring.
>>
>> <an example (as it happens in Oracle)>
>>
>> A row exists with some field value of 1. Two different threads
associated
>with different TXs want to increment this value by one. Thread A reads
the
>row, see val=1. Thread A updates the row to val = 2. No commit of the
TX
>yet.
>>
>> Then Thread B reads the row, sees val = 1 (default isolation used,
>read-committed). Then Thread B tries to update the row to val = 2, but
>hangs, because there is an uncommitted update on that row in another
TX.
>>
>> Thread A commits its TX. Now the update in Thread B's TX executes,
and
>the val is set to 2 (which is already is, due to Thread 1). Now Thread
B
>commits its TX. NO EXCEPTION IS THROWN.
>>
>> The val in the DB is 2.
>>
>> <end of example>
>>
>> So now, both threads have incremented the val by one, but the val has
only
>been incremented once, in effect. This is because Thread 2 was allowed
to
>update the row based on a read that became stale.
>>
>> Thread 2 getting an error an rolling back would be great. But it is
not
>happening. So, I am forced to use the following scheme: Delineating
betwen
>"reading" and "reading with the intention to write in the same TX".
the
>former is a SQL select, and the latter is a SQL select for update,
which
>will pessemistically lock the row from others attempting to do the same
>thing (but others may do a regular select).
>>
>> That will ensure that I don't get stomped-on changes (as in the
example),
>but complicates my business logic, as well as might reduce performance
(if
>there are cases where concurrent reads with the intention to write
could
>happen, but one thread ends up not writing).
>>
>> Can you comment on this? Are we on the same page?
>>
>> - Lawrence Bruhmuller
>>
>>
>
========================================================================
==
>> To unsubscribe, send email to [EMAIL PROTECTED] and include in
the
>body
>> of the message "signoff EJB-INTEREST". For general help, send email
to
>> [EMAIL PROTECTED] and include in the body of the message "help".
>>
>>
>
>
========================================================================
==
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
>
========================================================================
==
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
========================================================================
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
