Major transaction problem

[dmlloyd]

While working on bug JBPM-877 I discovered a bad problem. I ran a test in the web console which hit an error - probably a local configuration error - but the transaction committed even though the web console called jbpmContext.setRollbackOnly(). Could this be a consequence of the new transaction code? Maybe it is due to using JTA rather than CMT in the jbpm-enterprise.ear (which is where I saw this problem)?

Any ideas?

[tom.baeyens]

i don't have ideas. but that could very well be a problem.

is it reproducable ? if it is a bug as i expect, should be fairly easy to reproduce.

question is... how can we automate enterprise testing. i have done some cactus stuff. but i'm not sure if it will be easy to include tests with different jbpm configurations.

[dmlloyd]

is it reproducable ? if it is a bug as i expect, should be fairly easy to reproduce.

In the web console inside the EAR with my config modifications, it happens every time. But I don't have a separate test case yet. I'll try and get some more information - specifically I'm trying to figure out if this is specific to the EAR, or JTA, or whether it's just a new bug that was introduced in the transaction code.

[dmlloyd]

OK the bug also exists when I run the console as a standalone WAR so I'm thinking the bug is in the jBPM transaction code... zeroing in further

[dmlloyd]

OK looks like it's actually a hibernate problem. After rolling back the transaction and starting a new one, the domain objects still seem to contain the modified data from the previous transaction!

Hmmm...

[dmlloyd]

so: if I run jbpm-console.war (standalone), and a transaction fails, it is properly rolled back but the hibernate objects still contain the updated data (which makes sense I guess).

If I run the console from the EAR, the transaction is not rolled back and the database contains partially complete information.

[tom.baeyens]

from the hibernate reference

"
Rolling back the database transaction doesn't put your business objects back into the state they were at the start of the transaction. This means the database state and the business objects do get out of sync. Usually this is not a problem, because exceptions are not recoverable and you have to start over after rollback anyway.
"

so if there is a rollback, you (or I) should throw away the session and create a new one.

can you find how we could fix this ?

[dmlloyd]

Yeah, I can fix that problem. That still leaves the issue of transactions not rolling back (at all) in the jbpm-enterprise.ear, which I'm looking into now.

[dmlloyd]

Yes, JTA transactions in the EAR are majorly broken. The underlying exception *appears* to be:

java.lang.NullPointerException
at org.jbpm.persistence.db.DbPersistenceService.rollback(DbPersistenceService.java:304)
at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:238)
at org.jbpm.svc.Services.close(Services.java:222)

Investigating further.

[dmlloyd]

Okay, this just isn't making any sense. There are so many exceptions around rollback, things like "transaction already marked for rollback" and "could not register synchronization with JTA TransactionManager", that it's nearly impossible to figure out the underlying cause. What I *can* tell is that both hibernate and jBPM seem to be forcing a rollback on the transaction under some circumstances, and it seems like a new transaction may not be started afterwards.

Still trying to unwind the txn spaghetti.

[tom.baeyens]

maybe this is related and might give some more insight: http://jira.jboss.com/jira/browse/JBPM-833

[tom.baeyens]

i think i start remembering this problem...

the webapp cannot operate with the same hibernate configurations as the jbpm ejbs do. that is, untill the web app isn't refactored to using commands and a command service.

webapp needs JTA transactions and the context blocks in the webapp should have transactions enabled. these transactions then result in JTA transactions. that is necessary in case async node execution leads to messages being sent.

the jbpm ejbeans need CMT transactions (no transaction demarcation in code). i think the beans might be configured for JTA with transactions enabled, as they will always be inside a CMT method with tx-attribute required. So i think that hibernate will not end the JTA transaction if it didn't created it.

[dmlloyd]

Ok, I think this issue is resolved. Enabling transactions and clearing out the hibernate session data fixed it.