[jedizippy]

I am happy to use the test case I have. That is my whole point it is very basic but we have spent days trying to get it to work !!.

I should just rename the package name so its more anonymous :;. Let me know if you want me to do that and I can do it then maybe it could be a simple test case added to the release. If it helps then I have no issues doing that. In fact I will do it anyway as I am lucky to have the task of making all this work by 4th January or we will have to implement a different workflow engine.

And ......spoke to soon and we are back to the 4.2 constraint violation issues when the engine attempts to delete the process instance and history it fails with a constraint violation. So the continue="async" seems to have moved the problem later into the process but its still there !. What seems to be happening now is that while the subprocess has moved to a task state and is waiting there.....the engine is attempting to delete the parent process !!!!!! The task has continue="async" set also. Note here SIMPLE-ERROR is the key to the parent (master) process....while we are waiting for a signal still in the sub-process.

16:20:56,938 FIN | [HibernateSessionResource] ----- beginning hibernate tx 5784348 --------------------------------------------------------
16:20:56,961 FIN | [DbSessionImpl] deleting history process instance SIMPLE-ERROR.Order-1014656251
16:20:56,981 FIN | [DbSessionImpl] deleting process instance SIMPLE-ERROR.Order-1014656251
16:20:57,069 WRN | [JDBCExceptionReporter] SQL Error: 2292, SQLState: 23000
16:20:57,069 SEV | [JDBCExceptionReporter] ORA-02292: integrity constraint (JBPM.FK_EXEC_SUPEREXEC) violated - child record found

### EXCEPTION ###########################################
16:20:57,069 SEV | [AbstractFlushingEventListener] Could not synchronize database state with session
org.hibernate.exception.ConstraintViolationException: could not delete: [org.jbpm.pvm.internal.model.ExecutionImpl#20019]
     at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:94)

Should I raise a JIRA for this. As now we are back to the same problem that we cant use 4.2 and we cant use latest trunk as we have the timers issue.

Regards

Martin

[kukeltje]

jedizippy wrote:

I am happy to use the test case I have. That is my whole point it is very basic but we have spent days trying to get it to work !!.

Ok, if you clean it up, raise a jira issue for this example to be included in 4.4, then I'll take care of that.

jedizippy wrote:

And ......spoke to soon and we are back to the 4.2 constraint violation issues when the engine attempts to delete the process instance and history it fails with a constraint violation. So the continue="async" seems to have moved the problem later into the process but its still there !.

In 4.2 you mean? Well, you saw an issue being resolved for that in 4.2. If you do not want to wait for 4.3, you could checkout 4.2 and implement the patch yourself

jedizippy wrote:

What seems to be happening now is that while the subprocess has moved to a task state and is waiting there.....the engine is attempting to delete the parent process !!!!!! The task has continue="async" set also. Note here SIMPLE-ERROR is the key to the parent (master) process....while we are waiting for a signal still in the sub-process.

16:20:56,938 FIN | [HibernateSessionResource] ----- beginning hibernate tx 5784348 --------------------------------------------------------
16:20:56,961 FIN | [DbSessionImpl] deleting history process instance SIMPLE-ERROR.Order-1014656251
16:20:56,981 FIN | [DbSessionImpl] deleting process instance SIMPLE-ERROR.Order-1014656251
16:20:57,069 WRN | [JDBCExceptionReporter] SQL Error: 2292, SQLState: 23000
16:20:57,069 SEV | [JDBCExceptionReporter] ORA-02292: integrity constraint (JBPM.FK_EXEC_SUPEREXEC) violated - child record found

### EXCEPTION ###########################################
16:20:57,069 SEV | [AbstractFlushingEventListener] Could not synchronize database state with session
org.hibernate.exception.ConstraintViolationException: could not delete: [org.jbpm.pvm.internal.model.ExecutionImpl#20019]
     at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:94)

Should I raise a JIRA for this. As now we are back to the same problem that we cant use 4.2 and we cant use latest trunk as we have the timers issue.

Would be good to know if this error happens in 4.2 AND 4.3 (trunk) as well when the timers are removed. If so, it is a different issue and a jira should be filed. Otherwise you might want to try to backport the 4.3 patch to 4.2

[kukeltje]

Btw, change the xsd reference in your processdefinitions to 4.2 for the jpdl4.2 parser to be used. Otherwise the 'old' parser is used (4.0/4.1) and you will not fully profit from 4.2 functionality!!!

[jedizippy]

Hi,

I had already updated the xsd to 4.2 in order to allow the outcome-value stuff. I am working today on cleaning up this testcase and then I will post it up here. I am doing some more investigation today. One thing occured to me while doing this was that I was using one test case to invoke the process and get to the wait state and another seperate one to take the task and complete it. Hence there would have been 2 Job Executors running and maybe this is what could have caused some issues. But that would be a standard use case in a clustered environment.

I am not sure if that would be the case or not. As it should be possible to cluster jbpm so multiple Job Executors are running against the same DB so maybe I am barking up the wrong tree. We will be deploying our process engine to a WLS cluster - will have to consider the implications of that later if we get to that point. Will come back later with findings....

Cheers

Martin

[kukeltje]

I had already updated the xsd to 4.2 in order to allow the outcome-value stuff. I am working today on cleaning up this testcase and then I will post it up here. I am doing some more investigation today.

Great

One thing occured to me while doing this was that I was using one test case to invoke the process and get to the wait state and another seperate one to take the task and complete it. Hence there would have been 2 Job Executors running and maybe this is what could have caused some issues. But that would be a standard use case in a clustered environment.

I am not sure if that would be the case or not. As it should be possible to cluster jbpm so multiple Job Executors are running against the same DB so maybe I am barking up the wrong tree. We will be deploying our process engine to a WLS cluster - will have to consider the implications of that later if we get to that point. Will come back later with findings....

Yes, and jBPM supports this. No need to just run one jobscheduler anymore. But afaik, jBPM uses the ip address of the server for some things.  Multiple jobschedulers on the same machine could in that case result in strange behaviour. The sourcecode will tell you this, and please let me know to ;-)

[jedizippy]

Hi,

I have created jira JBPM-2706 and attached the simple unit test case.

Regards

Martin