Rickard Öberg wrote:
Hi!If this is not standard then shouldn't it be part of the deployment descriptor? One should be able to specify whether optimistic or pessimistic locking is used. Otherwise the bean may behave differently running in different containers or servers. Alternatively, one would have to code in such a way that the bean would work in either scenario.Thomas Hofmann wrote:
> I have one simple question:
>
> Assume there are an entity bean A and two users (clients) U1 and U2. U1
> finds the bean A with ejbFindByPrimaryKey(PK). He intends to update the
> data represanted by bean A.
> How can U2 be informed that bean A will currently be updated by another
> user if he also wants to update bean A (must U1 do a ORA SELECT FOR UPDATE in
> the ejbFind.. method see
> above)? U2 should be able to read the data but he has to know that he
> cannot change the data (He is reading old data). If I use isolation
> level "TRANSACTION SERIALIZABLE" then U1 won't be able to read the data,
> will it ?This is related to pessimistic vs optimistic locking. EJB containers can
be either, and the underlying database can be either. Normal transaction
settings will take care of the above. If you use optimistic locking then
clients will always be able to read data, but updates may fail. I
suggest that you read up on locking from any database book.
I have yet to hear a good standard solution for this fairly common scenario.
It appears as if you either have to rely on the specific container's functionality
or on database specific features. (such as select for update).
Question reality===========================================================================
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".
