I couldn't choose between the JMS/JCA/Performance forums, but I chose this one in the end. Any assistance with the issue below will be much appreciated.
I have a Stateless Session EJB (SSB). It is invoked from a webservice, although I do not believe the webservice facade is contributing to this problem. Part of the SSBs work is the publication of one or more messages to a JMS Queue. My performance concerns are related to commit times, which probably span two transactional resources (our database and the JMS implementation).
Immediately before the SSB returns to the JBoss container we (a) flush all SQL to our database, (b) take a timestamp using System.currentTimeMillis().
As soon as the afterCompletion() invocation is received on our Synchronization instance (registered with the transaction) we take another timestamp using System.currentTimeMillis().
The time taken is known as the TransactionEnding time, and we find it to be a substantial proportion of overall SSB business method execution time (often 100ms or more, which is over 75% of total business method execution). Other logging indicates that the commit to our database is particularly quick - in most cases just 10ms.
We urgently need to address the inordinant amount of time being used in the TransactionEnding phase.
Our environment is currently
AppServer: JBoss 3.2.3
JDK: Sun JDK 1.4.2_07
Database: Sybase 12.5.3
JDBC Driver: jConnect 6.0
JMS Persistence Service: Sybase-compatible implementation of org.jboss.mq.pm.PersistenceManager (see below), authored by Amresh Deshmukh and subsequently (I believe) contributed to the jboss poject.
public class PersistenceManager
implements PersistenceManagerMBean, org.jboss.mq.pm.PersistenceManager, org.jboss.mq.pm.CacheStore
We identified the storage of blobs into Sybase as being the determining factor. We moved from JBossMQ to ActiveMQ and this has delivered the performance and scalability we required (through its journal-based persistence backed by Apache/Derby).
Kind regards, Robin.