Well the Spec says threading violates the specs, and some people go even as far as saying that there should be "no threading primitives(i.e synchronized etc)" in the code. My question then is --- what about java utility classes themselves like HashTable etc & maybe code from 3rd party vendors for different components(especially if they exist in .class jars) --- how do we know what makes or breaks the specs.
Could some one try to explain this
Regarding the synchronization part, it is a pretty common question about the spec, which is also open for some interpretation. The particular spec rule is:
"An enterprise Bean must not use thread synchronization primitives to synchronize execution of multiple instances."
It seems quite clear to me that what the spec means is that you can't use synchronization *in an attempt to achieve synchronized behaviour between multiple instances of a bean*. The mere act of performing monitor operations (e.g. calling synchronized methods) is not illegal in my opinion, and there is no reason why it should be. The reason stated for the rule in the spec is:
"This rule is required to ensure consistent runtime semantics because while some EJB Containers may use a single JVM to execute all enterprise beans instances, others may distribute the instances across multiple JVMs.
... Synchronization would not work if the EJB Container distributed enterprise beans instances across multiple JVMs."
I think this means that the reason for the rule is only what I stated above, not some general conceptual problem with thread synchronization. Thread synchronization would simply not achieve the desired goal in some App servers, and therefore you as a developer must not use it in order to achieve that goal.
In practice, no matter what you do, you are bound to run synchronized code in your beans. String operations (even basic concatenation), Stream IO, Vector/Hashtable access and JDBC access are just some of the actions that are very likely to result in the running of synchronized code. Every library that uses a singleton is also bound to use synchronization. I find it hard to believe that the spec really ment to rule all of these libraries out.
The part about libraries that start off threads during their operation is more tricky. In that case, I do think running them would be in violation of the spec. One potential way to solve this problem is for that library to be installed as a J2EE connector (which has SPI interfaces to the app server for performing thread related operations). However, if you are not the designer of the library you probably couldn't you this solution. It is also quite a bit of work.
I think in most practical cases starting a thread should not have any fatal results, as long as it does not call back into the bean or attempt to access transactional resources. If you can make sure the thread terminates before the bean method returns thats probably safer.