>
If the analysis is correct then it appears as if there is another critical
mistake in the Pet Store demo which is part of the Sun BluePrints Guideline.
These misinterpretations of the EJB spec are a big problem. I have also found
several misinterpretations of the spec in several of the books out on EJB.
Where exactly does one go to get a definitive answer on the spec?
>
>
> > 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.
There are two problems with this approach.
1) It would cause all methods to block until completion; not just updateQuantity.
2) It is using a non-standard Oracle feature.
It would be great if you could just state in the deployment descriptor that calls
to the method updateQuantity should be serialized. Then the container can handle
it. That would solve both problems. This would be great not only for entity
beans but for session beans as well.
>
>
> 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 + ?;
>
This also would work, however the need to serialize calls to some methods will
probably appear in other kinds of transactions. For example. suppose you want to
do something like process an order. If there is enough quanity of a certain
item, place the order and decrease the amount. For example if the order is for
1 item you might say,
if (qty > 0) then place the order and decrease the inventory by 1.
To do this you will have to read the database to see if the qty>0, place the
order and decrease the inventory.
For such a case only your first approach will work.
Alternatively I guess you could do other things for such a case to avoid
blocking. For example you could do something like,
update qty set qty = qty - ? where qty > ?;
Then check to see if any rows are updated. If they are not then generate an
exception and let the order fail.
Maybe there is always a way to do this using features of the database rather than
features of EJB. It still seems to me that it would be nicer to be able to just
state that calls to certain methods should be serialized.
Is it legal to do things like set the isolation level of the transaction in the
bean's methods?
>
> 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".
===========================================================================
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".
