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".
