J2EE 1.4 and coherence

Question

I heard that J2EE 1.4 standards require not to spawn threads and new WebSphere will not allow such. Wanted to now what is your plan to support this

Answer 1

Nabil,
I presume you are referring to the restrictions in the EJB specification (section 24.1.2), which are intended to accomplish several things, including ensuring portability and security. The restrictions do not apply to the containers, libraries and components that the EJB utilizes, for example the application server itself or a JDBC driver that communicates over a socket, nor do the restrictions apply to core classes of Java that you may utilize from the EJB, for example the java.lang.String class. Each of the listed rules in the specification has an associated purpose (explanation) attached to it to provide a context for the rule. For example:
Rule: "An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or
use a socket for multicast."
Explanation: "The EJB architecture allows an enterprise bean instance to be a network socket client, but it does not
allow it to be a network server. Allowing the instance to become a network server would conflict with
the basic function of the enterprise bean-- to serve the EJB clients."
Rule: "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."
Explanation: "These functions are reserved for the EJB Container. Allowing the enterprise bean to manage threads
would decrease the Container’s ability to properly manage the runtime environment."
Generally, what this means is that the EJB itself should not try to make assumptions about its environment (for portability) or work around limitations of the environment (security). The classes and libraries that an EJB uses by matter of course are not held to the same restrictions. As one example, java.lang.String violates at least three of the rules set forth for EJBs (including thread synchronization, native code use, and use of static fields), yet String is a legitimate class to use within an EJB. Similarly, JDBC drivers may be implemented using native code, and may communicate over sockets; Oracle’s JDBC drivers do both, for example.
Since Coherence is supported on virtually all Java application servers and hardware/OS platforms, applications that use Coherence are further assured of their portability. Coherence does not take advantage of any vendor-specific libraries or features, and is completely server agnostic and built in pure Java. Coherence was carefully architected to use every resource sparingly and (as much as possible) asynchronously to facilitate the maximum scalable throughput.
Coherence elegantly fills a gap in functionality that otherwise presents a nearly unsolvable puzzle -- how to safely and efficiently manage data in the application tier that may be 'expensive' to get from a persistent store, and particular for data that are used often, ensuring that the cluster will scale as well as possible.
Regards,
Gene