[jbpm-dev] Help with ht problem? (Re: BZ 853019)

[Marco Rietveld]

Hi Maciej and Mauricio,

I'm struggling to find a good solution for a problem and was hoping to 
get your advice about the following.


The human-task service uses it's entities as DTO's, namely the Task 
class/instances.

However, we use Hibernate, which uses lazy-loading, which means that 
Hibernate substitutes proxy instances in collections until the actual 
collection elements are needed.

With Hibernate 3, we miraculously were able to avoid any large problems. 
However, testing with EAP 6 has uncovered situations, primarily with 
postgresql, in which this strategy (entity as DTO) just won't work.

The problem is that even if all the "persistence" work is done in one 
tx, the collections are still lazily-loaded. That means if a task 
service operation has to return a Task instance, that the serialization 
of the Task object (when it's being sent) triggers the loading of 
entities. Due to postgresql's Large Object facility, this means that 
there needs to be a transaction around this action. Because we don't 
surround the session.write(resultsCmnd); operation with a tx, we get an 
exception.

(To tell the truth, I don't understand why this worked with Hibernate 3.. )

As I've been writing this, I've come up with a couple of solutions:

1. Turn off lazy-loading for all entities.
2. Force the loading of all relevant entities by going through the 
object tree (task.getPeopleAssignments().size(), etc.. )
3. Put a transaction around session.write(resultsCmnd);

Option 1 has a big impact on performance, especially if we start talking 
about high-volumes.
Option 2 has a slightly larger impact on performance  but Option 3 seems 
a little bit ugly to me.


Are there any options I missed? Any advice or comments?

Thanks,
Marco

PS. This is (IMHO) one of the reasons we need to rewrite human-task. 
I've been working on a proposal/POC, but the important thing is that 
certain problems that we have now aren't also present in the rewritten 
version.

-- 
jBPM/Drools developer
Utrecht, the Netherlands