Win a copy of 97 Things Every Java Programmer Should Know this week in the Java in General forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

Scenario : Entity concurrent acess

 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 277
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Friends,

Thanks for your help !!
Thanks Keith, thanks Sudhir!!
WIlliam.
 
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
There are 10 kinds of people in this world. Those that understand binary get this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!
https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
    Bookmark Topic Watch Topic
  • New Topic