org.jbpm.JbpmException: couldn't start JTA transaction...

[fil78]

Hello everybody,

While I am trying to start my jBPM process I get this exception:

14:18:28,309 ERROR [JobExecutorThread] exception in job executor thread. waiting 1280000 millisecond
s
org.jbpm.JbpmException: couldn't start JTA transaction
 at org.jbpm.persistence.jta.JtaDbPersistenceService.beginJtaTransaction(JtaDbPersistenceService.jav
a:51)
 at org.jbpm.persistence.jta.JtaDbPersistenceService.<init>(JtaDbPersistenceService.java:28)
 at org.jbpm.persistence.jta.JtaDbPersistenceServiceFactory.openService(JtaDbPersistenceServiceFacto
ry.java:17)
 at org.jbpm.svc.Services.getService(Services.java:144)
 at org.jbpm.svc.Services.getPersistenceService(Services.java:183)
 at org.jbpm.JbpmContext.getPersistenceService(JbpmContext.java:628)
 at org.jbpm.JbpmContext.getJobSession(JbpmContext.java:561)
 at org.jbpm.job.executor.JobExecutorThread.acquireJobs(JobExecutorThread.java:112)
 at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:58)
Caused by: javax.transaction.NotSupportedException
 at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:79
)
 at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.begin(BaseTransactionManagerDelegate.java
:77)
 at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.begin(ServerVMClientUserTransaction.jav
a:124)
 at org.jbpm.persistence.jta.JtaDbPersistenceService.beginJtaTransaction(JtaDbPersistenceService.jav
a:49)
 ... 8 more

Could someone explain the reason? Thanks in advance.

[jhalliday]

Most likely an attempt to begin a transaction on a Thread that already has one, which is not allowed by default.

[fil78]

And is it possible to clean transactions stack? - because even after server restarting this transaction starts again - as I understand this transaction hanging over somewhere.

[jhalliday]

What evidence is that understanding based on?

[fil78]

Well.. - When I restart server in debug mode during the restarting (in its final stage) the process stops in a breakpoint.

[jhalliday]

and this breakpoint is set where exactly? Transaction.magicallyResurrect()? it would certainly have to be in some code that's specific to reinstating a pre-existing transaction on the thread, otherwise its irrelevant.

[fil78]

I have an action class of my jBPM process and this transaction invokes this class - here is the snippet:

@SuppressWarnings("unchecked")
 public void execute(ExecutionContext context) throws Exception {
 context.getContextInstance().setVariable("mess", mess);
 if (context.getContextInstance().getVariable("theBody") instanceof HashMap){
 System.out.println("Preparation of candidate to employee...");
 HashMap<String,String> tmp = null;
 tmp = (HashMap<String,String>)context.getContextInstance().getVariable("theBody");
 EmployeeInformationVO employee = new EmployeeInformationVO();
 Iterator<String> it = tmp.keySet().iterator();
 while (it.hasNext()) {
 String elem = (String) it.next();
 String value = (String)tmp.get(elem);
 if (elem.compareTo("s_name") == 0){
 employee.setSurname(tmp.get(elem));
 System.out.println("The candidate " + value + " was removed to the employee status");
 } else if (elem.compareTo("f_name") == 0){
 employee.setName(tmp.get(elem));
 } else if (elem.compareTo("city") == 0){
 CityVO city = new CityVO();
 city.setId(Long.parseLong(tmp.get(elem)));
 employee.setCity(city);
 }
 }


// pInfoInterface.addEmployee(employee);
 }
 }

Breakpoint is set in this line: context.getContextInstance().setVariable("mess", mess);

[jhalliday]

OK, let me see if I've understood this. When the app server starts up, it runs some of your business logic. You set a breakpoint in that business logic.

When the execution hits the breakpoint, you drop into the debugger and take a look around. There is an active Transaction on the Thread that is executing the business logic. You make a careful note of the transaction's identity.

You restart the execution, it throws an exception, per your first posting. You then stop and restart the app server.

It runs your business logic again, hits the breakpoint and, lo and behold, the same transaction you saw during the previous run is once again active on the Thread.

Based on this evidence, you believe 'even after server restarting this transaction starts again - as I understand this transaction hanging over somewhere.' i.e. the same Transaction has (re)started along with the app server. Is that right?

[fil78]

Yes. That is my thoughts... And because stack includes arjuna exceptions... - I must say I have not faced before JTA and JTS...

[jhalliday]

Hmm, fascinating case. Just out of curiosity, the transaction identity you made a careful note of and which reappears on the second run of the app server - what is it?

[fil78]

No - I have not made a note of transaction id - cause I do not know where could I find it. I just suspect that it goes like this....

[jhalliday]

Rather than treating the symptom by removing the unwanted transaction association from the thread (TransactionManager.suspend() BTW, and don't forget to resume it when you are done) perhaps it would be better to worry about why it's there in the first place? A Thread will not have a transaction associated to it unless something performs that association. Find whatever that is and make sure it's also cleaning up the association when it's done. The most likely problem here is failure to properly resolve an earlier transaction on the same thread.