> So how should one code for this properly? If the transaction isolation
> level is Serializable then an exception will be generated in the store
> method for the second transaction. This is not what we want to happen.
>
> Here are my questions.
>
> 1) Is my analysis correct?
Absolutely.
> 2) What is the correct way to code for this so that it works in any
> container?
Look for a different solution.
Two approaches. One, if you think that only one Bean will be used most
of the time you can acquire a lock using SELECT FOR UPDATE. The first
bean does a SELECT FOR UPDATE in ejbLoad, gets the quantity, changes it,
stores it back. Until the transaction has committed or rolledback the
second bean cannot touch the record.
This is nice and dandy but if you have multiple beans accessing the same
record (which I assume you are), then lock contention becomes a problem.
Approach number two, your bean now has a variable called incQty, each
time you update the quantity you do so by putting the change (positive
or negative) in incQty. When ejbStore is called instead of the
following:
UPDATE ... SET qty = ?;
you do the following:
UPDATE ... SET qty = qty + ?;
arkin
>
> Dan
>
> ===========================================================================
> 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".
