Question about how the JPA Persisted Process Variable Object works in a BoundaryMessage event

[muralimohan123]

Sorry, very new to Activiti.

Using Activiti 5.15.1, along with JPA and Hibernate 4

Assume, there is a process variable Object A, which is a JPA persisted Object. Once the process goes into waiting mode and is woken up by a Message event like a Boundary Message, how will the Object A work. How will it get associated with a hibernate session?  When the boundary message is trigger or send, it is done from a @Transactional method and the call is not synchronous, so the transaction is available, for Activiti.

I am mainly facing a problem where when the process wakes up after a Boundary message, the call to get a collection from A, say A.getChildren() fails with the message: org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: com.telrock.tsys_accounts.vo.PaymentPlanVO.paymentScheduleVOList4978.47
A.children, no session or session was closed

[jbarrez]

Activiti only stores the reference to the id, and then uses the Hibernate entityManager to ressurect it.
It would help a lot if you can craft us a simple unit test that demonstrates this problem, so we can troubleshoot and fix it.

[muralimohan123]

I have some more information. This is happening in a situation where there are 3 levels of processes - Process 1 calling Process 2, which calls Process 3. Or in other words, Process 3 is a sub process of Process 2 and Process 2 is a sub process of Process 1.

On querying Activiti tables, I see that the relevant Object appears as a jpa_entity along with the id in TEXT2_ in Process 1 and Process2. But in Process 3, it is a serializable and has null ID. it is in Process 3  that the Session closed issue happens. Why is the Process 3 considering the Object a Serilaizable and not a jpa-entity is a mystery. Any ideas? SQL output with some confidential information edited is given below.


mysql> select * from ACT_RU_VARIABLE v, ACT_RU_EXECUTION e where v.NAME_ like '%paymentPlan%' and v.EXECUTION_ID_=e.ID_;
+————————————–+——+————–+—————+————————————–+————————————–+———-+————————————–+———+——-+——————————————–+——–+————————————–+——+————————————–+—————+————+—————————————————————+————————————–+———+————+—————-+———–+—————–+——————-+——————-+————+
| ID_                                  | REV_ | TYPE_        | NAME_         | EXECUTION_ID_                        | PROC_INST_ID_                        | TASK_ID_ | BYTEARRAY_ID_                        | DOUBLE_ | LONG_ | TEXT_                                      | TEXT2_ | ID_                                  | REV_ | PROC_INST_ID_                        | BUSINESS_KEY_ | PARENT_ID_ | PROC_DEF_ID_                                                  | SUPER_EXEC_                          | ACT_ID_ | IS_ACTIVE_ | IS_CONCURRENT_ | IS_SCOPE_ | IS_EVENT_SCOPE_ | SUSPENSION_STATE_ | CACHED_ENT_STATE_ | TENANT_ID_ |
+————————————–+——+————–+—————+————————————–+————————————–+———-+————————————–+———+——-+——————————————–+——–+————————————–+——+————————————–+—————+————+—————————————————————+————————————–+———+————+—————-+———–+—————–+——————-+——————-+————+
| c6d636c6-d0ba-11e5-8e0b-d067e529f61b |    1 | jpa-entity   | domainObject | c6d54c65-d0ba-11e5-8e0b-d067e529f61b | c6d54c65-d0ba-11e5-8e0b-d067e529f61b | NULL     | NULL                                 |    NULL |  NULL | com.DomainObject | 18     | c6d54c65-d0ba-11e5-8e0b-d067e529f61b |    1 | c6d54c65-d0ba-11e5-8e0b-d067e529f61b | NULL          | NULL       | Process1:1:cd41d7a7-ba12-11e5-bec6-d067e529f61b | NULL                                 | NULL    |          0 |              0 |         1 |               0 |                 1 |                 0 |            |
| c6dacaaa-d0ba-11e5-8e0b-d067e529f61b |    1 | jpa-entity   | domainObject | c6da5579-d0ba-11e5-8e0b-d067e529f61b | c6da5579-d0ba-11e5-8e0b-d067e529f61b | NULL     | NULL                                 |    NULL |  NULL | com.DomainObject | 18     | c6da5579-d0ba-11e5-8e0b-d067e529f61b |    1 | c6da5579-d0ba-11e5-8e0b-d067e529f61b | NULL          | NULL       | Process2:3:d5007f1e-d0ac-11e5-9611-d067e529f61b     | c6da0758-d0ba-11e5-8e0b-d067e529f61b | NULL    |          0 |              0 |         1 |               0 |                 1 |                 7 |            |
| c78fea0b-d0ba-11e5-8e0b-d067e529f61b |    1 | serializable | domainObject | c78f74d9-d0ba-11e5-8e0b-d067e529f61b | c78f74d9-d0ba-11e5-8e0b-d067e529f61b | NULL     | c78fea0a-d0ba-11e5-8e0b-d067e529f61b |    NULL |  NULL | NULL                                       | NULL   | c78f74d9-d0ba-11e5-8e0b-d067e529f61b |    1 | c78f74d9-d0ba-11e5-8e0b-d067e529f61b | NULL          | NULL       | Process3:7:baf3c394-d0ba-11e5-8e0b-d067e529f61b  | c78ba447-d0ba-11e5-8e0b-d067e529f61b | NULL    |          0 |              0 |         1 |               0 |                 1 |                 7 |            |

[jbarrez]

"Why is the Process 3 considering the Object a Serilaizable and not a jpa-entity is a mystery."

No idea, to be honest. That should not happen.
As said above, a simple unit test with this use case and jpa would help us a lot in troubleshooting this.