Call activiti transaction issue

[rlefebvre]

Hello everyone,

I'm new to activiti development and we have a rather specific issue, therefore I will do my best to explain the situation a little bit:

Currently we have a correct working activiti process in production, and we are trying to develop a new one.
However our new activiti process does not function in the same way as our already deployed production process does.
And we can't define why at the moment.

The basic idea of our current situation is that when something goes wrong, we create a record in the database, and we execute a call activiti to a generic sub process. In that generic sub process we verify if in fact a record has been created and we await a manual user action on this created record. This generic sub process (triggered by a call activity) works fine in our working activiti process, but not in the new one we are trying to develop. The problem we have in our new activiti process is that allthough the creation of the record is executed (the dao call), it is not yet persisted in the database. Only at the end of the entire flow all records are inserted and persisted at once. But in our triggered call activiti sub process we assume this record is already created and persisted in the database. I am aware that activity handles it's transactions in a particular way, but since the difference to our working activiti process is not clear to me I created this topic.
The only difference between the two is that in our new process we have an extra call activity level, is it possible that that causes transaction issues?

So our question is how activiti manages transactions in combination with call activity's;
and whether it is possible that nesting call activity's can cause different behaviour (whyle we call the same generic sub process using call activity).


To become concrete:

In our working activiti process:

-> start root process

try{
//error occurs
}catch(){
//create user ticket
customDao.insertSpecificRecord();
}

–> call activity1
—-> In that activiti process we retrieve the created record (that is persisted through the call activity ?)

———————————————————————

In our failing activiti process:

-> start root process

–> call activity1

try{
//error occurs
}catch(){
//create user ticket
customDao.insertSpecificRecord();
}

——–> call activity2
———-> in this called activiti no ticket is found



I hope this is somewhat clear, but any help would be appreciated.
Thanks in advance.

[rlefebvre]

Hello everyone once again,

I just resolved my problem, and it turns out it was no transaction issue whatsoever.
It seems that it was a combination of things that made it very hard to retrieve this error.

But for the people that are interested I will try and explain what was wrong and why we couldn't find it right away.

First of all the DataSources of our transactions of our unit tests use are different than the dataSources for the transactions that the deployed applications use (the applications deployed on a local glassfish make use of a jndi connection while our unit tests use a DataSource defined in a spring applicationContext.xml file).
Since the processEngineConfiguration makes use of this datasource we had different transacyion behaviour in our unit tests (where the records were persisted immediatly), than the same code on the glassfish server (where the records were persisted at the end of our flow).

But it turned out the problem had nothing to do with this, I had configured an update to a call activity's root process incorrectly and since that update was never executed, the called acitivy process could not found our persisted record, and followed a different flow. But since I could not view the "live" records in the database I thought it had something to do with the activiti transaction throughout the call activiti processes.

But it turned out it was my own stupid mistake.

Thanks anyway

[ronald_van_kuij]

Glad you solved it and thanks for reporting. Always appreciate that