<div dir="ltr">Yes. I don't think we should be suspending the transaction.<div><br></div><div>Stuart</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 5, 2014 at 6:31 PM, James R. Perkins <span dir="ltr"><<a href="mailto:jperkins@redhat.com" target="_blank">jperkins@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
You're suggesting something more like<br>
<br>
TransactionManager.getTransaction().registerSynchronization(synchronization);<br>
<br>
Rather than the;<br>
<br>
TransactionManager.suspend();<br>
try {<br>
doStuff();<br>
} finally {<br>
TransactionManager.resume();<br>
}<br>
<br>
Am I understanding that correctly?<div><div class="h5"><br>
<br>
<div>On 02/04/2014 10:32 PM, Stuart Douglas
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">This all sounds like a very similar problem to what
we already do with EJB timers. Timers are transactional, if you
create or cancel a timer it does not take effect until the
transaction commits.
<div><br>
</div>
<div>The way this is accomplished is two fold:</div>
<div>- The data store is transactional (or semi-transactional
really in the case of the file data store, as we did not
develop a fully transactional file system just for this)</div>
<div>- Timers are not actually started or cancelled until the
afterComplete() synchronization runs.</div>
<div><br>
</div>
<div>I think it would make sense for JBeret to basically do the
same. I think it would be very surprising to the user if jobs
they started in transactions that abort just proceed as
normal.</div>
<div><br>
</div>
<div>Stuart</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Feb 4, 2014 at 11:53 PM, Jason
Greene <span dir="ltr"><<a href="mailto:jason.greene@redhat.com" target="_blank">jason.greene@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div><br>
On Feb 4, 2014, at 3:51 PM, Radoslaw Rodak <<a href="mailto:rodakr@gmx.ch" target="_blank">rodakr@gmx.ch</a>>
wrote:<br>
<br>
> Hi<br>
><br>
><br>
> Am 04.02.2014 um 22:16 schrieb Jason Greene <<a href="mailto:jason.greene@redhat.com" target="_blank">jason.greene@redhat.com</a>>:<br>
><br>
>><br>
>> On Feb 4, 2014, at 3:13 PM, Jason Greene <<a href="mailto:jason.greene@redhat.com" target="_blank">jason.greene@redhat.com</a>>
wrote:<br>
>><br>
>>><br>
>>> On Feb 4, 2014, at 3:01 PM, James R.
Perkins <<a href="mailto:jperkins@redhat.com" target="_blank">jperkins@redhat.com</a>>
wrote:<br>
>>><br>
>>>><br>
>>>> On 02/04/2014 12:40 PM, Scott Marlow
wrote:<br>
>>>>> On 02/04/2014 02:42 PM, James R.
Perkins wrote:<br>
>>>>>><br>
>>>>>> On 02/04/2014 08:16 AM, Jason
Greene wrote:<br>
>>>>>>> On Feb 4, 2014, at 9:56 AM,
Cheng Fang <<a href="mailto:cfang@redhat.com" target="_blank">cfang@redhat.com</a>>
wrote:<br>
>>>>>>><br>
>>>>>>>> On 2/4/14, 9:57 AM,
Stuart Douglas wrote:<br>
>>>>>>>>> I would use a
transaction synchronization, so you don't spawn the
other thread until the transaction is successfully
committed.<br>
>>>>>>>>><br>
>>>>>>>> yes, we could implement
it in wildfly-batch integration module.<br>
>>>>>>>>> What does the spec
say about transactions? If a job is create in a thread
that is part of a transaction and the transaction is
rolled back should the job actually go ahead? Common
sense would suggest not.<br>
>>>>>>>> The transaction
treatment in the batch spec is mostly around item
processing, not much on how it interacts with the
transaction in the running environment. The only place
that it touches on Java EE environment is section 9.7
Transactionality:<br>
>>>>>>>><br>
>>>>>>>> Chunk type check points
are transactional. The batch runtime uses global
transaction mode on the Java EE platform and local
transaction mode on the Java SE platform. Global
transaction timeout is configurable at step-level with a
step-level property:<br>
>>>>>>>><br>
>>>>>>>> Yes, I agree if the
batch client side transaction is rolled back, the job
execution should not proceed. With the current jberet
impl, the job execution in this case will fail since the
job repository is not in good state, like in the above
bug. If we have transaction syncrhonization in place,
then the job will not start running till transaction 1
is committed.<br>
>>>>>>> There is a consistency
problem here though. If you expect the client side to
rollback on transaction failure, then the in-memory job
store should as well. IMO before committing to such a
big feature, I would recommend looking at what the RI
does here. If the spec doesn’t describe it, and the RI
doesn’t do it, then we should avoid investing time on it
at least right now where we really need to get WF8 out
the door.<br>
>>>>>> I don't see in the spec where
it requires any kind of transaction around<br>
>>>>>> a job repository. In fact the
spec states "Note the implementation of<br>
>>>>>> the job repository is outside
the scope of this specification.".<br>
>>>>>><br>
>>>>>> The RI does have a JDBC
repository, but it doesn't insert anything into<br>
>>>>>> the tables in a transaction.<br>
>>>>>><br>
>>>>>> If we're only seeing this in
PostgreSQL and a workaround with putting<br>
>>>>>> JobOperator.start() outside a
transaction works, I would suggest that's<br>
>>>>>> okay for now. I do agree it
needs to be fixed, but we might want to look<br>
>>>>>> at how we're handling
transaction in JBeret as a whole. The RI, not that<br>
>>>>>> I want to model anything after
it, uses it's own<br>
>>>>>> TransactionManagerAdapter. It
might make sense for JBeret to use a<br>
>>>>>> TransactionManager rather than
a UserTransaction. Or put the ownness on<br>
>>>>>> the SPI implementation of the
BatchEnvironment to handle the transactions.<br>
>>>>><br>
>>>>> Are you saying that the application
should work around this by calling a different bean
method that is marked NOT_SUPPORTED to facilitate
suspending the JTA transaction?<br>
>>>> No I'm just saying they need to invoke
the JobOperator.start() outside a transaction. At least
from my understand on the JIRA that seems to workaround
the issue. I will admit to not fully looking into this
in detail though ;)<br>
>>><br>
>>> That would be silly :)<br>
>><br>
>> Requiring a NOT_SUPPORTED method that is. It’s
pretty easy for JBeret to isolate the transaction if it
wanted to<br>
>><br>
>> tx = TransactionManager.suspend()<br>
>> TransactionManager.begin()<br>
>> // write the record<br>
>> TransactionManager.commit()<br>
>> TransactionManager.resume(tx);<br>
>><br>
><br>
> What will happened to suspended Transaction when
you get Exception on TransactionManager.commit() ?<br>
<br>
</div>
</div>
You put resume in a finally block. Just like RequiresNew
effectively does.<br>
<div><br>
--<br>
Jason T. Greene<br>
WildFly Lead / JBoss EAP Platform Architect<br>
JBoss, a division of Red Hat<br>
<br>
<br>
</div>
<div>
<div>_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
wildfly-dev mailing list
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></pre>
</blockquote>
<br>
</div></div><div class="im"><pre cols="72">--
James R. Perkins
Red Hat JBoss Middleware</pre>
</div></div>
</blockquote></div><br></div>