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.
Joined: Nov 21, 2000
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?
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.
Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
Joined: Oct 18, 2004
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.
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.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Nov 21, 2000
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 ]