Scenario : Entity concurrent acess

[William Silva]

Hi Friends,
Who could describe the scenario when two (or more) clients acess the same entity bean (at the same time) ? Will they share the same EJBObjetc ?
I didn't find this scenario in the HF book.
Thanks,
Wiliam.
[ January 14, 2004: Message edited by: William Silva ]

[Sudhir V]

Yes in case of concurrent access clients will have reference to the same EJBObject. They will have each have their own stub but they all communicate to the same Remote EJBObject. Please refer to the HF book Pg 99 "Architectural overview: Entity Beans"

[William Silva]

Hi Sudhir,
But... if two clients try to acess the bean at the same time ?
For example :
Client 1 call the method setName("Client1");
Client 2 call the method setName("Client2");
How will be the name after the transactions end ?
Thanks,
William.

[Sudhir V]

The same question I asked my database lecturer when she was teaching transactions in databses :-) (I mean its a Classic question). Concurrency here basically means that the entity is not locked for a specific client.
Coming to concurrent requests, its more of an implementation thing. First of all its kind of rare for this kind of concurrent request and remember when we deal with computers we speak about nanoseconds.
Consider the tradeoff btw locking the entity for a client vs ur question. Have you ever tried bidding any item on the ubid.com website duing the last minutes of closing an item...........

[William Silva]

Hi Sudhir,
>Coming to concurrent requests, its more of an implementation thing. First >of all its kind of rare for this kind of concurrent request and remember >when we deal with computers we speak about nanoseconds.
It is rare but... If it happens.
There are no ways to prevent it ?
Why both clients will use the same EJBObejct ? Is it just to save resources ?
Thanks,
William.

[Keith Rosenfield]

Hi all:
The container is responsible for managing entity bean concurrency. The container can choose any synchronization strategy that it wants. For more details refer to the spec section 10.5.10.

Hope this helps.

[William Silva]

Hi Friends,

Thanks for your help !!
Thanks Keith, thanks Sudhir!!
WIlliam.

[Reid M. Pinchback]

Originally posted by William Silva:
For example :
Client 1 call the method setName("Client1");
Client 2 call the method setName("Client2");
How will be the name after the transactions end ?

Actually, to make this clearer it helps to have a slightly more complex example:
Client 1: call setName("Client1"), setValue(1)
Client 2: call setName("Client2"), setValue(2)
If the two method invocations by each client are wrapped in a transaction then you are guaranteed that the resulting (name,value) state will either be ("Client1",1) or ("Client2",2), but not a mish-mash. Which you get will depend on the order in which the client transactions were initiated (the second transaction would block until the first had completed as soon as the transaction tried to access a resource already required by the first transaction).
Sometimes it is easy to psych yourself into thinking that something bad is happening when two clients are working at more-or-less the same time, but as long as the results are consistent (not a mish-mash), then it really isn't any different than the situation when the client activities are days apart. The first client changed the state. The second client changed the state. The final result is determined by who went last.
Where things get a bit wierd is when you are changing state based on stale information (e.g. read an entity bean, stuff data in a web page, customer submits a change, use entity bean to save change). The wierdness comes from the fact that you don't have a single transaction. You don't get this problem when a session bean reads and writes an entity bean in the same transaction, because the entity bean has a lock on the row in the database until the transaction is committed.

[Reid M. Pinchback]

One refinement to that... whether or not the entity bean retains a lock on the row depends on how the bean is implemented or on how the container is configured. At the highest transaction isolation level what I said would be true.