• Post Reply Bookmark Topic Watch Topic
  • New Topic

synchronized key word

 
Edy Yu
Ranch Hand
Posts: 264
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understand (according to EJB spec), sychronized key word is prohibited on EJB's methods. The reason for that is not very clearly stated in the spec. Anybody can help me understand it?

How about on the methods for POJOs in the container? Can we put that key word?

There are some confusions on this topic when I talk to J2EE developers. Some of them just totally avoid using that in their project since u think EJB spec says so.

But I think differently ...
 
Damanjit Kaur
Ranch Hand
Posts: 346
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We use synchronized to lock a group of statements i.e. when a thread executes those statements, some other thread can't execute/enter that block,until the first thread is finished with it. In EJB when a call to Bean's method is made, an instance of that bean is associated with EJB object and call is delegated to the associated bean instance. Though many clients can access the same EJB object but only one client can use the bean instance associated with that EJB object at anyone time. i.e. when a method call by a client to some bean instance is finished, only then some other client's call to some method on the same bean instance can be executed. So there is no need to use synchronized keyword. we use it to protect the changes made by one thread from being tampered by another thread. This state never arises in EJB.
 
Edy Yu
Ranch Hand
Posts: 264
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your reply.

However, you stated just what a thread synchronization is about. Not specific to the container controled enviroment.

According to the spec:
"An enterprise Bean must not use thread synchronization primitives to synchronize execution of multiple instances."
"This rule is required to ensure consistent runtime semantics because while some EJB Containers may use a single JVM to execute all enterprise bean�s instances, others may distribute the instances across multiple JVMs."
"Synchronization would not work if the EJB Container distributed enterprise
bean�s instances across multiple JVMs."

This is understandable because of the EJB's distributed nature. However, if we sychronize methods of POJOs (some people call them utility classes in the container), should not we consider the same premise as the spec reasoned?
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the issue is not where you put the synchronized key word, but what is the path of thread execution. You may use the keyword within a POJO method, but imagine what happens if that method is invoked by an EJB? The thread of execution originating from an EJB method now has a potential to suffer the same consequences as one that does not have an EJB context.

So in essence, it may be okay to use synchronization within a POJO class but it has indirect consequences on the EJB that executes it. If you have a thread path that does not originate from an EJB, for instance a POJO that starts a thread to perform some routine activity, then you'll be fine.
 
Damanjit Kaur
Ranch Hand
Posts: 346
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When I talked about Ejb object and associated bean instances, that meant about container controlled environment for entity beans. The Ejb container is itself taking care of synchronization and so no need to use this keyword and in distributed environment this container controlled behaviour is not effective.

But I don't understand why its stated in books that one must not use synchronized keyword. Whether we use it or not, in fact it won't make any difference in case of entity beans and in case of session beans-for statefull as I read in book it states- A stateful bean is an extension of one client and serves only that client. So here too no need to use synchronized keyword.

For stateless an instance can serve many clients as the state between different method calls is not maintained. Here I am not sure as to why one should not use synchronized within method bodies. The book only mention about the shared variables states which is not maintained in stateless.

So for POJO(if you will be using session beans to call POJO), synchronized can be used and should be used as here concurrency is not being controlled by the container.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You use synchronized to control access to a resource that can be shared by multiple threads. The container won't cause a session bean instance to be shared by two threads, so there should be no need to synchronize them. But, if two bean instances are adding and removing items from a shared cache, you might get into trouble. We have some synchronized methods in our POJOs for things like that. Course that doesn't mean it was a good idea, so I'm still interested in other opinions.
 
Edy Yu
Ranch Hand
Posts: 264
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Stan's opinion, even though we still need to think carefully about the thread synchronization issue in a distributed environment because of the possible multi-JVM, multi-container configuration in which the sychronization may not work as expected.

Damanjit Kaur, I think you confused thread synchronization with entity state synchronization. Two different concepts.
[ February 03, 2005: Message edited by: Edy Yu ]
 
Damanjit Kaur
Ranch Hand
Posts: 346
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes I also think so
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!