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

Maciej Swiderski mswiders at redhat.com
Thu Sep 13 03:15:16 EDT 2012


Marco, why we need to do that? Can't we just use it as is, meaning that 
several operations will be included in same transaction, like start, 
complete for example? Will this break on query level or ...
I am not sure how often it is used like that - two task service 
operations in single task service session?

I can see that in some cases beneficial (like all or nothing) and in 
some cases not really welcome (inserting users/groups - one fails roll 
backs all others).

Thanks
Maciej

On 12.09.2012 23:56, Marco Rietveld wrote:
> Maciej,
>
> I was thinking about that -- but doing that breaks the 
> LocalTaskService (or otherwise, we have to rewrite LocalTaskService so 
> that it opens a new TaskServiceSession for every operation, just the 
> way the TaskServerHandler handles that).
>
> Actually, the more I think about that, the better it sounds. It might 
> impact the performance of LocalTaskService slightly, but it will be 
> worth it, I think.
>
> Thanks,
> Marco
>
> 12-09-12 17:16, Maciej Swiderski:
>> 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 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.
>>>
>>
>
>



More information about the jbpm-dev mailing list