• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Entity Bean cuncurrency

 
Francesco Marchioni
author
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear all,
still studying Entity beans.
About Entity Beans cuncurrency I can read "Entity beans represent data that is shared and may be accessed concurrently
EJB addresses the dangers associated with concurrency in entity beans by prohibiting concurrent access to bean instances. In other words, several clients can be connected to one EJB object, but only one client thread can access the bean instance at a time" (from "Mastering EJB")

So I have build a simple use case with an Entity bean which has a long duration method:


I expected that access to this method would be synchronized...so that for example when a client calls withdraw() another client connecting would get stuck until the first one terminated the method.

But it's not such.
Clients can call this method cuncurrently.

So what is actually synchronized ? just get/set methods that modify data on DB ?
Hope somebody can shed some light on this....
Thanks
Francesco
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For one, your test already violates "Bean law", the EJB 2.1 specification.
Chapter 25 Runtime Environment
25.1 Bean Provider�s Responsibilities
25.1.2 Programming Restrictions
page 563

The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread�s priority or name. The enterprise bean must not attempt to manage thread groups.


Originally posted by Francesco Marchioni:
So what is actually synchronized? just get/set methods that modify data on DB ?


Your test assumes that synchronization will occur on your method.

The container can do anything it wants as long as it adheres to the specification. Remember that the container implements the class at deployment time. There is nothing stopping the server from doing some code analysis on the abstract class that you supply. So in the implementation class they could somehow inject the start of synchronization right before the first cmp/cmr field access and an end of synchronization right after the last cmp/cmr field access in order to guarantee the shortest possible locking time.

Your test method only accesses cmp/cmr fields after coming out of suspension. So synchronization doesn't have take place until after the "sleep" - so both clients can sleep concurrently.

In this case, all the implementation class would have to do, is to have accessors and manipulators that detect that access is not synchronized and then obtain the lock. The method itself would be extended to include code at the end that detects whether the lock is being held - in which case it would release the lock.
[ October 14, 2005: Message edited by: Peer Reynders ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic