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

Maciej Swiderski mswiders at redhat.com
Thu Sep 13 03:09:21 EDT 2012


Hi Eric,

currently I don't run any stress tests in strict meaning of those tests, 
especially with comparison to current implementation. However I don't 
see how changing place of starting/completing transaction will affect 
performance. Maybe I am missing a essential point here, if so appreciate 
explanation.

Currently transaction will be started inside some methods of task 
service session like addTask, taskOperation, etc. I suggested to move 
that little bit up and control it on session level, whenever it is 
created it will start transaction and when session is closed(disposed) 
transaction will be committed.

Thanks for comments
Maciej

On 13.09.2012 04:19, Eric D. Schabell wrote:
> Hi Maciej,
>
> Did you or are you also running some stress testing on these adjustments?
>
> One of the things we are struggling with is how this thing performs. 
> Marco is right on the money as far as I am concerned. I am just afraid 
> patches to this will not perform well in the current model. What do 
> you mean below when you say it worked fine? That it did not break any 
> existing unit tests?
>
> Just my 2cents, erics
>
> On Wed, Sep 12, 2012 at 11:16 PM, Maciej Swiderski 
> <mswiders at redhat.com <mailto: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 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-dev mailing list
>     jbpm-dev at lists.jboss.org <mailto:jbpm-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/jbpm-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbpm-dev/attachments/20120913/6274deb2/attachment-0001.html 


More information about the jbpm-dev mailing list