<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Mauricio, <br>
<br>
I think you might have either read the e-mails too quickly or
otherwise not understood them. If you get a chance, it would be
great if you could go through them again. <br>
<br>
<br>
Thanks,<br>
Marco<br>
<br>
13-09-12 22:36, Mauricio Salatino:<br>
</div>
<blockquote
cite="mid:CANzbnyXiUUe66Vud9ftRC74tO2g4qFkVoK4sxUoT5fyBFH91PQ@mail.gmail.com"
type="cite">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.
<div>
<br>
</div>
<div>The CDI/Weld module covers all the other cases and provides a
rock solid programming model that we should follow.</div>
<div><br>
</div>
<div>Cheers<br>
<br>
<div class="gmail_quote">On Wed, Sep 12, 2012 at 6:58 PM, Marco
Rietveld <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mrietvel@redhat.com" target="_blank">mrietvel@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Mauricio,<br>
<br>
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.<br>
<br>
Thanks,<br>
Marco<br>
<br>
12-09-12 23:16, Salaboy:
<div class="HOEnZb">
<div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
Cheers<br>
<br>
Sent from my iPhone<br>
<br>
On 12 Sep 2012, at 12:16, Maciej Swiderski <<a
moz-do-not-send="true"
href="mailto:mswiders@redhat.com" target="_blank">mswiders@redhat.com</a>>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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 <a moz-do-not-send="true"
href="https://issues.jboss.org/browse/JBPM-3763"
target="_blank">https://issues.jboss.org/browse/JBPM-3763</a>
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.<br>
<br>
Wdyt?<br>
<br>
Maciej<br>
<br>
On 12.09.2012 12:22, Marco Rietveld wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Maciej and Mauricio,<br>
<br>
I'm struggling to find a good solution for a
problem and was hoping to get your advice about
the following.<br>
<br>
<br>
The human-task service uses it's entities as
DTO's, namely the Task class/instances.<br>
<br>
However, we use Hibernate, which uses
lazy-loading, which means that Hibernate
substitutes proxy instances in collections until
the actual collection elements are needed.<br>
<br>
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.<br>
<br>
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.<br>
<br>
(To tell the truth, I don't understand why this
worked with Hibernate 3.. )<br>
<br>
As I've been writing this, I've come up with a
couple of solutions:<br>
<br>
1. Turn off lazy-loading for all entities.<br>
2. Force the loading of all relevant entities by
going through the object tree
(task.getPeopleAssignments().size(), etc.. )<br>
3. Put a transaction around
session.write(resultsCmnd);<br>
<br>
Option 1 has a big impact on performance,
especially if we start talking about high-volumes.<br>
Option 2 has a slightly larger impact on
performance but Option 3 seems a little bit ugly
to me.<br>
<br>
<br>
Are there any options I missed? Any advice or
comments?<br>
<br>
Thanks,<br>
Marco<br>
<br>
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.<br>
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
<br>
</div>
</div>
<div class="HOEnZb">
<div class="h5">
-- <br>
jBPM/Drools developer<br>
Utrecht, the Netherlands<br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
- MyJourney @ <a moz-do-not-send="true"
href="http://salaboy.wordpress.com" target="_blank">http://salaboy.wordpress.com</a>
<div> - Co-Founder @ <a moz-do-not-send="true"
href="http://www.jugargentina.org" target="_blank">http://www.jugargentina.org</a><br>
- Co-Founder @ <a moz-do-not-send="true"
href="http://www.jbug.com.ar" target="_blank">http://www.jbug.com.ar</a><br>
<br>
- Salatino "Salaboy" Mauricio -</div>
<br>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
jBPM/Drools developer
Utrecht, the Netherlands</pre>
</body>
</html>