It appears you are assuming a long transaction model, controlled by the
client. This is appropriate if you can afford to hand out a datasource
connection to every user that might be updating simultaneously.
If you are building large system, and need to always MUX your db
connections, then you need to consider soft locks. See the archives...
-Chris.
> -----Original Message-----
> From: Thomas Hofmann [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 25, 2000 2:46 AM
> To: [EMAIL PROTECTED]
> Subject: Entity bean and locking a row
>
> Hi,
>
> 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 scenrio can happen inside a update/maintenance GUI dialog. But
> customers
> want be informed before they open the update dialog with a little message.
> The data is only for reading displayed !
>
>
> Any help will be appreciated
>
> ==========================================================================
> =
> 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".
