XA transaction performance

Question

Hi,
I'm using Weblogic for JMS (using MDB to process messages) and Coherence as a Caching solution. My MDBs are under transaction and I want to perform operations on Coherence using the same transactions. to do such a thing I installed Coherence JCA connector and use the Adapter.
This seems to be working, however I have a big performance impact (my thoughput is divided by 4 or 5) Is this a normal behavior ?
In my code I'm maybe doing a mistake: I create a cache for each message :
adapter = new CacheAdapter(ctx, "tangosol.coherenceTx",
CacheAdapter.CONCUR_OPTIMISTIC,
CacheAdapter.TRANSACTION_GET_COMMITTED, 0);
NamedCache cache = adapter.getNamedCache("dist-test",
getClass().getClassLoader());
Can I create the adapter in the init method of the mdb ? I don't think so because of the transaction for the Initial context...
Luc

Answer 1

Hi Luc,
sorry, I misunderstood you, I thought that using no database also means no JMS either, because if the JMS queue uses a JDBC message store (which we normally used so that we can get resource joining by using the same connection pool / datasource as our data access code is using), then you in fact are using a database.
If you use only a JMS queue and Coherence and if it is possible to recognize redelivery of messages from the data in Coherence caches and data in the message, then I would still suggest managing your own Coherence transaction with TransactionMap-s (and throw a RuntimeException/EJBException if commit to Coherence failed) and upon processing the message you should do the redelivery check. This would allow Weblogic to optimize away using XA for the JMS delivery transaction as the only transactional resource in that transaction would be the JMS queue itself.
If it is impossible to recognize redelivery, then you should probably use the CacheAdapter.
I only wish that the JNDI lookup in the CacheAdapter constructor could be replaced with something else, since according to our profiling in an earlier project, it was taking the largest part of the CacheAdapter construction and initialization. The connect() call can probably not be avoided but that took only one third of the time the JNDI lookup took.
Best regards,
Robert