If components A and B are session beans, then you are on your own as far as
synchronizing access to the dB. I will assume they are entity beans.
It is unclear from your description whether components A and B are instances
of the same entity bean class. If so, then they should have the same
primary key, given that they represent the same data. (If they don't have
the same PK, see "Chip's disjoint object graph rule" below). The next
question that must be considered is "what transactions are involved in this
example and how they are demarcated?". It is up to the container to allow
or disallow two instances of the same bean class representing the same PK to
run in parallel in two different transactions. From section 9.5:
The enterprise Bean developer does not have to worry about
concurrent access from multiple transactions when writing the business
methods. The enterprise Bean developer writes the methods assuming that the
container will ensure appropriate synchronization for entity Beans that are
accessed concurrently from multiple transactions.
On the other hand, if components A and B are instances of different entity
bean classes, then there is a design flaw in the component model.
Chip's disjoint object graph rule:
In general, each entity bean instance should represent a graph of domain
object instances which is disjoint from (does not intersect) the instance
graphs represented by other entity bean instances of the same or different
entity bean classes.
It is Ok, for example, for a Company entity to refer to an Address somewhere
in its graph and also for a Client entity to refer to an Address somewhere
in its graph, but if a given Company entity and a given Client entity refer
to the same address object stored in a single location in the persistent
store, then you have an invalid component model. To fix this, there are
many things you could do, the most obvious (but probably not desirable)
would be to make the Address object an entity in and of itself, and then the
Company and Client entities could refer to the same Address entity. At this
point the container will manage concurrent access from two transactions if
the situation arises.
> -----Original Message-----
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Sunday, April 04, 1999 4:47 PM
> To: [EMAIL PROTECTED]
> Subject: Lost Updates and EJB
>
> Hi all,
>
> I've been dusting off my old database book recently, and I've run
> into an
> interesting problem in transactions -- the Lost Update. A lost update
> occurs in
> a scenario such as the following. Assume two components A and B
> concurrently
> perform these operations:
>
> 1 Component A reads integer X from the database. The database now
> contains X =
> 0.
> 2 Component B reads integer X from the database. The database now
> contains X =
> 0.
> 3 Component A adds 10 to its copy of X, and persists it to the database.
> The
> database now contains X = 10.
> 4 Component B adds 10 to its copy of X, and persists it to the database.
> The
> database now contains X = 10.
>
> Thus Component A's update has been lost.
>
> Can someone reason to me which EJB transaction isolation level(s)
> explicitly
> protect against Lost Updates, and how it protects against them?
>
> Thanks
> -Ed
>
> ==========================================================================
> =
> 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".
