topic Re: Activiti transaction + JEE transactions in Alfresco Archive

Activiti transaction + JEE transactions

jsher — Tue, 03 Jan 2012 15:49:41 GMT

Hi,Apologies for these basic questions - I have limited JEE knowledge, but here goes…I am trying to build a picture of how Activiti will behave in a JEE setting, particularly from a persistence/transactions point of view. I am considering only JEE6 container managed persistence for the moment. I see

Re: Activiti transaction + JEE transactions

trademak — Thu, 05 Jan 2012 18:28:09 GMT

Hi,

Did you look at the Activiti CDI module? Because this provides integration with JEE 6 and EJB's.

Best regards,

Re: Activiti transaction + JEE transactions

meyerd — Thu, 05 Jan 2012 20:11:47 GMT

Hi James,

Q1 yes
Q2 yes

Q3 We do not provide support for this. You could write your own JobExecutor and delegate Job acquisition & execution to JEE-container-managed threads there.
Q4 If you configure activiti with JTA, a JTA transaction will be opened for executing the job and if you invoke a SessionBean, the transaction context will be propagated to that bean.

Re: Activiti transaction + JEE transactions

meyerd — Thu, 05 Jan 2012 20:14:25 GMT

Maybe as an additional side note:
- we are currentls looking into refactoring the JobExecutor, so that self-management of Threads is factored out and you can plugin your own Thread-management strategy: ACT-34
- I will write a bolg post shortly on activiti integration with websphere application server 8.

Re: Activiti transaction + JEE transactions

jsher — Thu, 12 Jan 2012 13:41:40 GMT

Thanks Tijs. Yes the CDI support is certainly very useful as a starting point.

Regards
James

Re: Activiti transaction + JEE transactions

jsher — Thu, 12 Jan 2012 13:51:12 GMT

Thanks Daniel for your very helpful replies.

Q3
- re. writing my own JobExecutor… I suspect that JobExecutor is not pluggable currently so I guess this would require custom changes to Activiti which I wouldn't be too keen to do having limited knowledge of the internals. Ideally the experts like yourselves would provide such functionality assuming of course there are sufficient requests for this type of feature.

Q4
- I'm still unsure though if there is an issue with a thread not managed by the container (assuming I don't do custom JobExecutor) invoking EJBs. I need to dig into JEE/EJB more to answer this - or maybe someone reading this knows the answer ?

Regards
James

Re: Activiti transaction + JEE transactions

meyerd — Thu, 12 Jan 2012 14:35:00 GMT

Hi James,

Q3
- re. writing my own JobExecutor… I suspect that JobExecutor is not pluggable currently so I guess this would require custom changes to Activiti which I wouldn't be too keen to do having limited knowledge of the internals. Ideally the experts like yourselves would provide such functionality assuming of course there are sufficient requests for this type of feature.

I will merge branch ACT-34 shortly, that will make it a lot easyer to implement JobExecutor delegating to Threads of your choice (ie. "supported", Container-Managed Threads in an App Server)

Re: Activiti transaction + JEE transactions

pangea — Thu, 12 Jan 2012 15:20:47 GMT

Maybe as an additional side note:
- we are currentls looking into refactoring the JobExecutor, so that self-management of Threads is factored out and you can plugin your own Thread-management strategy: ACT-34
- I will write a bolg post shortly on activiti integration with websphere application server 8.

Wondering if thread management is pluggable in 5.8. We might want to use spring task executor.

Re: Activiti transaction + JEE transactions

meyerd — Thu, 12 Jan 2012 15:30:00 GMT

Hi pangea,

not in 5.8

Re: Activiti transaction + JEE transactions

pangea — Thu, 12 Jan 2012 15:31:52 GMT

Hi pangea,

not in 5.8

Could you please let me know the approximate version when this will be included?

Re: Activiti transaction + JEE transactions

jsher — Thu, 12 Jan 2012 17:18:34 GMT

Hi James,

I will merge branch ACT-34 shortly, that will make it a lot easyer to implement JobExecutor delegating to Threads of your choice (ie. "supported", Container-Managed Threads in an App Server)

Daniel, will these scheme work for jobs initiated by timer events (boundary, intermediate) ? What I mean is we need to have Activiti continue to execute tasks which flow from timer events as it does currently but to do so in CM threads. The custom JobExecutor would only provide CM thread to Activiti when timer event fires, Activiti then continues to execute the flow as defined in the process.

Does this make sense ?

Regards
James

Re: Activiti transaction + JEE transactions

pkonyves — Sun, 21 Oct 2012 13:36:09 GMT

Hi,

This topic is useful but I'm still unsure about the behaviour of Activiti in regard to JTA Transactions. I have the same setup as the original poster's:
JtaProcessEngineConfiguration, transactionsExternallyManaged=true

some part of my process definition setup is such:

+—————————————————–+
|  user_task_a –> service_task –> user_task_b       |
|                                                     +—+
|    [Error boundary event]                           |   |
+————-|—————————————+   |
              |                                           |
              +–>handle_error—————————-+–>O

In the JavaDelegate of service_task I call EJB methods with default transaction attribute: Required.

Q1) When I complete user_task_a from Activiti GUI will I have a started transaction in the service_task?
Q2) When I complete user_task_a from code in my own service layer, will I have a transaction in the service_task?
Q3) When I complete user_task_a from code within EJB that started a transaction, will activiti use this transaction or create a new one?

Q4) If There is already a started transaction in the service_task – assumingly activiti already started one at the completion of user_task_a – in which I invoke the EJB. And EJB throws EJBTransactionRolledBack exception, will it roll back the transaction started by activiti?

My use case is that we have several service tasks, that may generate errors. What we do is we create our process definitions in a subprocess and use an Error boundary event that leads to a "handle error" user task in case any error.
The scenario is this: If something goes wrong in service task, we catch the exception, set a variable and throw a BpmnError exception to fall into the "handle error" task.
My problem is that I don't see right now if an error happens in my EJB that is called from service task, how it will affect the workflow. If the error triggers a transaction rollback, will it roll back the activiti transaction as well and eventually the state won't change?

My solution would be this to my problem: I would set the transactionAttribute of my EJB called from service task to "requiresNew". This way if something goes wrong in the EJB, it will not affect the activiti transaction.

Any suggestions about this approach?

Thank you for your help!

Re: Activiti transaction + JEE transactions

frederikherema1 — Mon, 22 Oct 2012 09:21:07 GMT

Q1: Yes, activiti will request a new transaction from the underlying transaction mechanism, in your case, JTA

Q2: If your own service-layer uses JTA-transactions, activiti (when completing task) will use the existing JTA-trasaction (underlying transaction-mechanism returns the active one to activiti). If your own service IS NOT transactional, activiti will get a new JTA-transactions as wit Q1.

Q3: If the EJB uses JTA, then yes, activiti will participate in this transaction.

Q4: That's what JTA is for… If configured correctly (using XA if needed), exceptions in YOUR code or Activiti code will roll back both. So when "completing" a task and an exception is thorn somewhere while executing the process, it's rolled back to the initial state. So the "complete" never happened

If you're service-calls to EJB and it throws an exception, it's very likely that the proxy around the EJB will cause the transaction to be marked as "rollback only", depending on the configuration of the EJB and the rollback-behaviour. So if you want to have your EJB be rolled back, but you're handling the error inside the process (BPMNError) it makes sense to use a new transaction for the service-call. However, it's not guaranteed that these 2 transactions (in case of success) both get committed… This may cause invalid state in your process vs. your own model

Re: Activiti transaction + JEE transactions

pkonyves — Mon, 22 Oct 2012 09:47:55 GMT

frederikheremans:
Thanks for clearing these up. I'm familiar with JTA in the context of EJBs, but was not sure how it cooperates with activiti.

I'm now concerned about this "it's not guaranteed that these 2 transactions (in case of success) both get committed".
In which cases does not both transactions will be committed? It would be essential to know if I go with this approach.

Do you have a better idea about error handling in service tasks?

Re: Activiti transaction + JEE transactions

frederikherema1 — Mon, 22 Oct 2012 12:33:27 GMT

If you have 2 transactions, one for activiti, and another one (forced created by the REQUIRES_NEW) for your beans/services. In case the service-call is done, the REQUIRES_NEW transaction is committed. Then, when activiti engine flows on, it's possible that, after the service-task call, something goes wrong (no DB, another service-task fails, optimistic locking, …) the activiti-transaction is rolled back.

This leaves your own services' data-mutations committed and activiti's reverted back to the state it was in, causing a difference. So having your services FORCE a new transaction, is generally a bad idea if you want to be absolutely safe.

Or am I missing something?