12 Replies Latest reply on Mar 9, 2007 12:59 PM by David Lloyd

    Major transaction problem

    David Lloyd Master

      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?

        • 1. Re: Major transaction problem
          Tom Baeyens Master

          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.

          • 2. Re: Major transaction problem
            David Lloyd Master

             

            "tom.baeyens@jboss.com" wrote:
            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.

            • 3. Re: Major transaction problem
              David Lloyd Master

              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

              • 4. Re: Major transaction problem
                David Lloyd Master

                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...

                • 5. Re: Major transaction problem
                  David Lloyd Master

                  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.

                  • 6. Re: Major transaction problem
                    Tom Baeyens Master

                    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 ?

                    • 7. Re: Major transaction problem
                      David Lloyd Master

                      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.

                      • 8. Re: Major transaction problem
                        David Lloyd Master

                        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.

                        • 9. Re: Major transaction problem
                          David Lloyd Master

                          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.

                          • 10. Re: Major transaction problem
                            Tom Baeyens Master

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

                            • 11. Re: Major transaction problem
                              Tom Baeyens Master

                              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.


                              • 12. Re: Major transaction problem
                                David Lloyd Master

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