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

[Mauricio Salatino]

For the remote services layers (the transports layers) DTOs can be added,
there is not need of more mechanisms for that. It sounds that you are
trying to cover uses cases that are not usually required, you want to keep
inside a transaction an object that is being sent through the wire. For
those kind of scenarios you can use specifications like WS-Transactions,
but I don't believe that it worth it and we should not be focused on that.

The CDI/Weld module covers all the other cases and provides a rock solid
programming model that we should follow.

Cheers

On Wed, Sep 12, 2012 at 6:58 PM, Marco Rietveld <mrietvel at redhat.com> wrote:

> 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 at redhat.com> 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/browse/JBPM-3763>which 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
>
>


-- 
 - MyJourney @ http://salaboy.wordpress.com
 - Co-Founder @ http://www.jugargentina.org
 - Co-Founder @ http://www.jbug.com.ar

 - Salatino "Salaboy" Mauricio -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbpm-dev/attachments/20120913/8952fc77/attachment.html