[camunda]

Here the datasources:

 <local-tx-datasource>
 <jndi-name>jdbc/MysqlJMSDS</jndi-name>
 <connection-url>jdbc:mysql://localhost:3306/esb</connection-url>
 <driver-class>com.mysql.jdbc.Driver</driver-class>
 <user-name>root</user-name>
 <password>root</password>
 <idle-timeout-minutes>5</idle-timeout-minutes>
 <connection-property name="autoReconnect">true</connection-property>
 <max-pool-size>75</max-pool-size>
 <blocking-timeout-millis>10000</blocking-timeout-millis>
 <check-valid-connection-sql>select 1</check-valid-connection-sql>
 <metadata>
 <type-mapping>mySQL</type-mapping>
 </metadata>
 </local-tx-datasource>

 <local-tx-datasource>
 <jndi-name>jdbc/MysqljBPMDS</jndi-name>
 <connection-url>jdbc:mysql://localhost:3306/esb</connection-url>
 <driver-class>com.mysql.jdbc.Driver</driver-class>
 <user-name>root</user-name>
 <password>root</password>
 <idle-timeout-minutes>5</idle-timeout-minutes>
 <connection-property name="autoReconnect">true</connection-property>
 <max-pool-size>75</max-pool-size>
 <blocking-timeout-millis>10000</blocking-timeout-millis>
 <check-valid-connection-sql>select 1</check-valid-connection-sql>
 <metadata>
 <type-mapping>mySQL</type-mapping>
 </metadata>
 </local-tx-datasource>

I asked around for the property and there were some issues causing arjuna to throw an exception if not set this way in some circumstances... Don't got any details yet.

But I changed the property locally back to false, no difference in the described behavior...

[kconner]

This is definitely one configuration issue but I suspect it is not the only one. I am still going through the remainder of the logs.

If you have multiple last resources then you will lose the atomic guarantee of a transaction, as well as risking heuristics if there are any issues during commit. You need to look at changing this.

I'll follow up again when I have managed to go through everything.

[kconner]

Can I ask you to try two things, to see if this helps.

First, can you drop all the jUDDI tables before starting the server. It looks like you may have a number of EPRs hanging around from previous runs.

Second, can you make the following change to your JBoss ESB service configuration and trying again?

<jms-jca-provider name="JMS-Provider" connection-factory="java:/XAConnectionFactory">

If this change works then I believe I can explain the problem.

[camunda]

1) I deleted the old EPRs, seem to be some relics from slaughtering down JBoss a couple of times over the last weeks ;-)

2.) Yeah, that solved the problem! I am really curious about the announced explanation :-) I thought "java:JmsXA" should be JTA too?

Cool, I should send you an extra large Christmas parcel!

[kconner]

"camunda" wrote:
2.) Yeah, that solved the problem! I am really curious about the announced explanation :-) I thought "java:JmsXA" should be JTA too?

It is JTA but it is a pool which is controlled by the JCA layer. It looks like it was the interaction between that pool and ours which was the problem, especially as our pool was initially seeded outside a transaction and we could not determine, from the interface, that it was transactional.

The jca provider requires you to specify two groups of settings, those for the JCA provider used by the service (it defaults to JBoss configurations) and those used by the clients. The connection factory is one of the ones necessary for the clients and should point to the real connection factory.

"camunda" wrote:
Cool, I should send you an extra large Christmas parcel!

Well, before you do I have one more request :)

Can you change java:/XAConnectionFactory to just XAConnectionFactory? This will use the global JNDI reference and should allow you to use it outside of the VM, if necessary.

Sorry it took so long to get here.

[camunda]

Hi Kevin.
Thanks a lot for investigating so hard and really helping me out!! Currently I am not in the office of that project for 2 to 3 weeks and don't have the environment on my computer, but I will have a look as soon as I return and let you know...

Cheers
Bernd

[camunda]

Okay, I could try today: Works as well with the "XAConnectionFactory". Thanks again!

[camunda]

Hi Kevin.

We discussed this issue today and are still a little bit puzzled:

The XAConnectionFactory is the same as the ConnextionFactory, it is just another name in JNDI. I tried and it works with the ConnectionFactory as well. This is the configuration in JBoss messaging:

 <mbean code="org.jboss.jms.server.connectionfactory.ConnectionFactory"
 name="jboss.messaging.connectionfactory:service=ConnectionFactory"
 xmbean-dd="xmdesc/ConnectionFactory-xmbean.xml">
 <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
 <depends optional-attribute-name="Connector">jboss.messaging:service=Connector,transport=bisocket</depends>
 <depends>jboss.messaging:service=PostOffice</depends>

 <attribute name="JNDIBindings">
 <bindings>
 <binding>/ConnectionFactory</binding>
 <binding>/XAConnectionFactory</binding>
 <binding>java:/ConnectionFactory</binding>
 <binding>java:/XAConnectionFactory</binding>
 </bindings>
 </attribute>
 </mbean>

So why is this transactional? Or is it always transactional?

And a colleage pointed me to the hajndi-jms-ds.xml:

 <!-- JMS XA Resource adapter, use this to get transacted JMS in beans -->
 <tx-connection-factory>
 <jndi-name>JmsXA</jndi-name>
 <xa-transaction/>
 <rar-name>jms-ra.rar</rar-name>
 <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
 <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
 <config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/DefaultJMSProvider</config-property>
 <max-pool-size>20</max-pool-size>
 <security-domain-and-application>java:/messaging</security-domain-and-application>
 </tx-connection-factory>

This is why the idea was to use the JmsXA. Would be cool if you could give another short explanation.

Thanks a lot!!

[kconner]

The difference is not between the definition of ConnectionFactory and XAConnectionFactory as they are indeed the same. It was the use of java: in the name as that scope is not always visible to the caller of a service.

As for the difference between ConnectionFactory/XAConnectionFactory and JmsXA, the issue lies with the class exposed through JNDI, how the XA resource is enlisted into the transaction and the fact that we have our own pooling mechanism.

For ConnectionFactory/XAConnectionFactory the object in JNDI implements both javax.jms.ConnectionFactory and javax.jms.XAConnectionFactory and, as such, our pool is aware of the capabilities and can control the enlistment of the XA resources within the transaction.

For JmsXA there are two issues that concern us. The first is that the JNDI object only exposes the javax.jms.ConnectionFactory interface so our pooling does not see the XA capability and treats it as a non-transactional resource.

The second issue is that the automatic enlistment of the underlying resource (by JCA) depends on when the connection was created and this was the problem you were seeing. Your connection had initially been created when there was no active transaction and, therefore, was not automatically enlisted by JCA when it was reused from within jBPM.

Our current requirement is that we assume control of the enlistment and, therefore, need to use XAConnectionFactory implementations.

Sorry for the confusion.

Kev