Support JMS 2

[pasfilip]

I wanted to try the new jms 2 feature for setting the delivery delay in the message producer but atomikos does not support this.

This is the error message I received:

java.lang.AbstractMethodError: Receiver class com.atomikos.jms.internal.AtomikosJmsMessageProducerWrapper does not define or inherit an implementation of the resolved method 'abstract void setDeliveryDelay(long)' of interface javax.jms.MessageProducer.

I'm having issues with what I though was commit ordering.
So I implemented the suggestion https://www.atomikos.com/Documentation/CommitOrderingWithJms
However it doesn't solve the issue.
When receiving the message the changes made in the db in a previous listener are not visible yet and causes issue.
So I wanted to test adding a delivery delay to see if it solve this issue but jms 2.0 is not supported.

Is there any plans to support jms 2? Is this on the roadmap for the product?

[GuyPardon]

JMS 2.0 is on the backlog, probably for release 6.0 but with no concrete release date yet.

Strange that the commit ordering does not work. Are you doing transactions across REST calls?

[pasfilip]

No rest calls involved.
We received messages using IBM MQ, update the db which is DB2 and send a message to trigger the aggregation.
When trying to aggregate we don't see the previously updated data causing the aggregation to never complete.

[pasfilip]

I just noticed in one location the wrong connection factory is injected.
I will update run some tests keep u posted.

[pasfilip]

Fixing the configuration did solve my problem!
We do have about 15% regression in performance but that's a trade-off I'm willing to make to keep the code free from any
hacks, like the message delivery delay, which would also impact performance and offer no real guarantees, and have a correct end result.
Thx for the feedback.
I suppose you can close this issue since you already have jms 2 on the backlog.

[pasfilip]

Note that it would be a nice feature if Atomikos could do this out of the box.
We are using more resources just to solve this issue. (more connections to broker needed)
If atomikos could analyze the resource when it's registered to try and determine the commit order would be nice.
Another alternative which I think of is to add a weight to the wrappers used.
We use AtomikosConnectionFactoryBean and AtomikosDataSourceBean it could maybe be an option to add a weight that influences commit order.
It would surely be an extra sales argument to buy into the atomikos eco-system...

[GuyPardon]

Thanks for the feedback!

What / how exactly do you think we could analyse the resource and determine the commit order?

[pasfilip]

I don't think there is a perfect solution, for that the xa spec for java would have to be revised and xa providers might have to implement extra code to enable some kind of weight assignment to the xa resource.
I was thinking you could perhaps analyze the class of the xa resources added to the transaction and attempt to determine if it's a jms resource, jdbc or other.
Maybe an idea could be to allow users to configure a map that maps resource class to a weight?
Or perhaps based on the package of the class.
For db2 something like resources belonging to package com.ibm.db2.jcc
For ibm mq something like com.ibm.mq
Atomikos could come with a map with defaults shipped with perhaps the option to add more via config or replace the map via config. Or provide an empty map by default and let users configure it if needed for an application.
If there is no mapping some default weight could be used.
Just throwing some ideas around not sure about the feasibility though...

[pasfilip]

Perhaps an another idea, not sure if possible is to have classes like AtomikosConnectionFactoryBean and AtomikosDataSourceBean
implement xa resouce wrappers that can provide a weight that influences commit order.

[GuyPardon]

Thanks - if we were to add weights then it would not need XA extensions, we could do everything in our core, in a similar way as you suggest. This could be something to consider, but only as part of a 6.0 release since it would impact the core of our commit processing.

[pasfilip]

That would be a nice improvement!