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).
I could also use some of the other schemes that have been outlined in this thread.
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".
