dan benanav wrote:
> > 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.
Only methods that attempt to retrieve the exact same entity (or page in
Oracle).
> 2) It is using a non-standard Oracle feature.
Actually supported in most of the database servers, including Sybase,
SQL-Server, PostgreSQL, DB2. Oracle was the only one to break due to
page level locking.
> 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.
I agree.
I would definitely like to see synchronized access to methods managed by
the server, and I can't understand why it's not in the 1.1 specs.
> 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.
This is a sort lived transaction, so SELECT FOR UPDATE is less of a
concurrency issue (though, slightly better). Sadly, there is no better
solution.
Even if you synchronize methods calls, remember that the data is
external to the EJB server. Anyone else can come in and modify it. It
can be another application using JDBC directly, another EJB server, a
different bean in the EJB server, etc.
> 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.
Or a stored procedure.
> 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?
No. The isolation level of a transaction can only be decided when the
connection to the database is first obtains. If you make multiple method
calls in the same transaction, only the first one can affect the
isolation level. Because the beans cannot guarantee in which order they
are called, this is a dangerous behavior and has been deprecated.
You can, however, define multiple datasources and decide,
programatticaly and through coordination which one to use. Each
datasource would map to the same database but use a different isolation
level.
arkin
>
> >
> > 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
