jBPM 4.3 - Which JTA config to use for non-JBoss platform.

[jedizippy]

Hi,

Whilst investigating an issue (and during an upgrade process) to 4.3 running on WLS I have attempted to include the jbpm JTA configuration in our jbpm.cfg.xml as follows (as per a recent update to the docs):-

<import resource="jbpm.tx.jta.cfg.xml"/>

This immediately failed during the engine initialization as the TransactionManager and the UserTransaction are not found in JNDI. Upon inspection of the code it is immediately apparent given the first two lines of code in:-

org.jbpm.pvm.internal.tx.JtaTransaction

The offending lines of code:-

public static final String JNDINAME_USERTRANSACTION_JBOSS_GLOBAL = "UserTransaction";
public static final String JNDINAME_TRANSACTIONMANAGER_JBOSS_GLOBAL = "java:/TransactionManager";

Hence this will of course not work on another other server than JBoss. These settings should come from my jbpm.hibernate.cfg.xml where the following properties should be used:-

    <property name="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</property>
    <property name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.WeblogicTransactionManagerLookup</property>

    <property name="jta.UserTransaction">java:comp/UserTransaction</property>
    <property name="jndi.class">weblogic.jndi.WLInitialContextFactory</property>

So is it my confusion. Should this <import resource="jbpm.tx.jta.cfg.xml"/> be used only in JBoss platform and on other platforms the default hibernate configuration used <import resource="jbpm.tx.hibernate.cfg.xml"/>. .Or is it a bug in the code ?.

In addition I am more concerned by the following line of code in the actual method that gets the context from JNDI:-

public static Object lookupFromJndi(String jndiName) {
    try {
      InitialContext initialContext = new InitialContext();
      return initialContext.lookup(jndiName);
    } catch (Exception e) {
      throw new JbpmException("couldn't lookup '"+jndiName+"' from jndi: "+e.getMessage()+": "+e.getMessage(), e);
    }
  }

This will of course result in memory leaks and eventual file descriptor issues as the InitialContext is not closed.

Regards

Martin

[jedizippy]

Does anyone have an answer to this JTA question !? Which config should jBPM 4.3 be using with JTA on a non-JBoss platform ?.

Regards

Martin

[kukeltje]

Can this be related: https://jira.jboss.org/jira/browse/JBPM-2349

[jedizippy]

Does seem to be in the same area but not sure if its directly related or not. It appears to be related to interceptors so possibly Spring related and we are not using Spring !.

Interestingly we had removed the continue="async" off the custom and task node in our subprocess and we ran back into ConstraitnVilolations again on the JBPM4_EXECUTION table so we have put them back on again and the probelm goes away. There is definitely a bug in the id generation in that area but we dont sadly have the time to look into it unless we hit a wll we cant pass again. I guess this issue wont show up in the test suite in the distribution as those tests dont use the JobExecutor so the issue wont arise !.

It would seem that either no one is using JTA in 4.X or else if they are then maybe only on jBoss. Hoping someone might look at the question today as it should be a simple question to answer !.

Regards

Martin

[jedizippy]

I guess the lack of response to this question speaks for itself !?

[pedrajaj]

I was hitting the same problem getting 4.3 running on WLS 10.3.  I found the following JIRA case on it https://jira.jboss.org/jira/browse/JBPM-2694. I updated it with the workaround I am using at the moment.

Ideally, the JNDI names to be used for the JTA transaction should be configurable through the configuration xml.

[jedizippy]

Hi Juan,

I agree the JtaTransaction class should be getting those values from the hibernate config xml file. I may take a shot at implementing a new version of JtaTransaction which implements the Command<T> to try and get those from hibernate but to be honest as this needs to be done for all non JBoss servers the changes should really be made in the trunk code as otherwise everyone using Jta will have to implement this !. As JTA is pretty much bread and butter in a real world production environment I wonder how many people are really running on non-JBoss platforms !.

I have voted for the JIRA anyway.

Thanks for the tip.

I notice you are running on DB2 with 4.3. Did you see any issues with ID generation and integrity constraints as with sub-processes on DB2 as well as Oracle is has been seen in JTA environments. We seem to have solved it by implementing our own generation. Would be interested to know if you are using sub-processes and if you have come across this !.

Regards

Martin

[kukeltje]

Command<T> to try and get those from hibernate but to be honest as this needs to be done for all non JBoss servers the changes should really be made in the trunk code as otherwise everyone using Jta will have to implement this !.

If you have a test, I'm more then willing to test it on JBoss and if it works, check it in.

I wonder how many people are really running on non-JBoss platforms !.

jBPM3 a lot, jBPM4 not sure. The jta transaction jndi name is (afaik) only a problem on WLS the other appservers have it identical to JBoss so....

[jedizippy]

Hi Ronald,


I have now implemented a modified version of the JtaTransaction class which gets the TransactionManager and User Transaction from the Hibernate configuration (or else defaults them to the JBoss ones if they are not defined). This is working in WLS so it just needs to be tested on JBoss. I dont have a test case. All you need to do is take the modified class and the new Command class and rebuild the pvm. It should work as it does now!.

Let me know how you want me to send you the changes. I can also send you the Oracle ID generation stuff if you want to add that ?.

Regards
Martin

[kukeltje]

Sure we are interested. Please attach it to this post in any form you like... I'll give it a try then and it might even be in time to go into 4.4.

Regarding the id generator, previous 4.0/4.1 releases used the id generator that best fits the database. Unfortunately (and I have no clue why) there were issues with at least MySQL restarting the server and doing strange things. Why the choice was made to try to implement something that I'd suspect e.g. Hibernate would have solved already is unknown to me. But please attach that to if you can.

Ronald

[kukeltje]

On second thought (after reading your pm) attach it to the Jira. I'll certainly have a look.