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

Mauricio, Unless you changed the API so that the DTO being used is not the same as the entity, your rewrite with CDI/etc. has the same fundamental problem. Thanks, Marco 12-09-12 23:16, Salaboy: I'm on PTO now, but that's or of the reason why I choose to use > cdi/weld/seam to re write the ht module, the extended persistence context > and the programming model push you to avoid having those issues. As soon as > I came back I will finish the spring integration and I will try to deliver > a feature complete alpha module. > Cheers > > Sent from my iPhone > > On 12 Sep 2012, at 12:16, Maciej Swiderski <mswiders(a)redhat.com&gt; wrote: > > Marco, another way could be to ensure transaction is started when >> taskservicesession is created and closed (committed/rolledback) when >> taskservicesession is disposed, I did that for a fix on >> https://issues.jboss.org/**browse/JBPM-3763<https://issues.jboss.org/b... is on postgresql and worked fine. So that way we ensure that >> session.write is in transaction as well. Of course not tested all possible >> cases but worked for main ones. >> >> Wdyt? >> >> Maciej >> >> On 12.09.2012 12:22, Marco Rietveld wrote: >> >>> 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