[ https://jira.jboss.org/jira/browse/JBPM-1775?page=com.atlassian.jira.plug... ] Alejandro Guizar reassigned JBPM-1775: -------------------------------------- Assignee: Alejandro Guizar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-1775?page=com.atlassian.jira.plug... ] Tom Baeyens commented on JBPM-1775: ----------------------------------- in case an exception comes out of user code, we'll add a check to see if the current transaction is still active before scanning the exception handlers. that way we can keep the lazy initialization. we'll mark the following known limitation in the documentation: if your user code marks the jta transaction for rollback, then you are not allowed to have exception handlers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-1775?page=com.atlassian.jira.plug... ] Alejandro Guizar resolved JBPM-1775. ------------------------------------ Resolution: Done Check for an active transaction (or no transaction) before invoking an exception handler. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-1775?page=com.atlassian.jira.plug... ] Mark Torres commented on JBPM-1775: ----------------------------------- This is causing issues on an app that I'm working on that uses seam. We are using <field name="isTransactionEnabled"><false/></field> and this is causing isAbleToHandleExceptions to always return true, even if the jta transaction is already rolledback. GraphElement proceeds to fetch the exceptionHandlers lazily and throws jta resource exception, instead of the original exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-1775?page=com.atlassian.jira.plug... ] Bernd Ruecker commented on JBPM-1775: ------------------------------------- Hi. The current commited fix doesn't work. The code isAbleToHandleExceptions has a bug, this was the check made: JbpmContext jbpmContext = executionContext.getJbpmContext(); if (jbpmContext != null) { Services services = jbpmContext.getServices(); if (services != null) { Service service = services.getPersistenceService(); if (service instanceof DbPersistenceService) { DbPersistenceService persistenceService = (DbPersistenceService) service; return persistenceService.isTransactionActive() || persistenceService.getTransaction() == null; } } } Unfortunately, the persistence.getTransaction() returns null in case the transaction is marked for rollback (at least in our case). And persistenceService.isTransactionActive() returns still true! I changed the code (and committed) to return persistenceService.getTransaction() != null && persistenceService.isTransactionActive(); But I guess it would be even better to do: return persistenceService.getTransaction() != null && persistenceService.isTransactionActive() && !persistenceService.isTransactionRollbackOnly(); Or to change the isTransactionActive() implementation (which I didn't want to touch ;-)). Maybe Alex can have a look on it? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-1775?page=com.atlassian.jira.plug... ] Alejandro Guizar commented on JBPM-1775: ---------------------------------------- The way I see it, the real bug is the "|| persistenceService.getTransaction() == null" part, which somehow managed to slip trough. The specific DbPersistenceService class in use should have full control over telling whether a transaction is in course or not. In the JtaDbPersistenceService case, getTransaction() will always return null. DbPersistenceService determines if the transaction is active as follows: public boolean isTransactionActive() { return transaction != null && transaction.isActive(); } which, provided we remove the "transaction == null" part, gives the same result as your proposed change, Bernd. I am not sure I agree with the .isTransactionRollbackOnly() addition, since a transaction marked for rollback may still perform work. Particularly it would render nontransactional exception handlers useless. For JtaDbPersistenceService we have: public boolean isTransactionActive() { SessionFactoryImplementor sessionFactory = (SessionFactoryImplementor) getSessionFactory(); return JTAHelper.isTransactionInProgress(sessionFactory); } JTAHelper queries the JTA transaction manager directly and does not rely on any local state. public static boolean isTransactionInProgress(SessionFactoryImplementor factory) { TransactionManager tm = factory.getTransactionManager(); return tm != null && isTransactionInProgress( tm.getTransaction() ); } Mark, I believe your issue is best addressed by switching to JtaDbPersistenceServiceFactory, which implicitly sets isTransactionActive to false and currentSessionEnabled to true. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBPM-1775?page=com.atlassian.jira.plugin.sy... ] Michel Rasschaert commented on JBPM-1775: ----------------------------------------- I think the fix proposed does not work completely. {{JTAHelper.isTransactionInProgress}} returns {{true}} even when a transaction is MARKED_ROLLBACK. Because of this we have lazy loading errors when an exception is raised. (see [JBPM-681] I think JtaDbPersistenceService#isTransactionActive should return true only if the transaction status is ACTIVE -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira