If for some reason you are unfortunate enough to have to use SunONE
Advanced Server 7 (variously known as as7se, SunONE AS7, Sun Java
System Advanced Server, etc.) and have to integrate it with Tibco’s
JMS server (Tibco EMS), here is what you need to do.

App server configuration

If for some reason you are unfortunate enough to have to use SunONE
Advanced Server 7 (variously known as as7se, SunONE AS7, Sun Java
System Advanced Server, etc.) and have to integrate it with Tibco’s
JMS server (Tibco EMS), here is what you need to do.

App server configuration

Put the Tibco client JARs (jndi.jar, jms.jar and tibjms.jar) in
$SUNONE/share/lib. Add them to the server’s classpath. In the server
admin console, navigate to:

In ejb-jar.xml, make sure the transaction type is “Bean” (see
Transactions below). The resource reference should refer to the
resource defined in sun-ejb-jar.xml above. Note that the
“res-ref-name” in these two files is independant of the JNDI name of
the actual resource (that is, they must only match each other).

SunONE mdb concurrency notes

Default pool settings allow mutiple beans to be created. They appear
to be created (constructor/ejbCreate()) on demand, but then stay in
the pool.

The onMessage() calls run on multiple threads, but there appears to be
reuse (i.e. threads that have finished executing an onMessage() will
be used again).

Setting the pool to have a max of one bean (bean-pool/max-pool-size)
causes messages to be consumed serially by one instance of the bean,
in one thread (as expected).

And interestingly (although not all that relevant), all the beans seem
to get constructed by the same thread, and that thread doesn’t do any
message servicing. But there does seem to be a 1:1 relationship
between bean instances and message servicing threads (although this is
with only six beans in the pool, it could be different with lots
more).

If there is only one bean in the pool, it is still constructed on a
different thread to that on which is processes messages.