<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 2/4/14, 9:57 AM, Stuart Douglas
wrote:<br>
</div>
<blockquote
cite="mid:CAAoo=c4J4n5CrEXJawZutQ3Npmv9+Rj2M6+7tLVMp6jkQPy=+w@mail.gmail.com"
type="cite">
<div dir="ltr">I would use a transaction synchronization, so you
don't spawn the other thread until the transaction is
successfully committed.
<div><br>
</div>
</div>
</blockquote>
yes, we could implement it in wildfly-batch integration module.<br>
<blockquote
cite="mid:CAAoo=c4J4n5CrEXJawZutQ3Npmv9+Rj2M6+7tLVMp6jkQPy=+w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>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.</div>
</div>
</blockquote>
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>
<br>
Thanks,<br>
Cheng<br>
<blockquote
cite="mid:CAAoo=c4J4n5CrEXJawZutQ3Npmv9+Rj2M6+7tLVMp6jkQPy=+w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Stuart</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Feb 4, 2014 at 4:49 PM, Cheng
Fang <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:cfang@redhat.com" target="_blank">cfang@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"> A jberet user
reported <a moz-do-not-send="true"
href="https://issues.jboss.org/browse/JBERET-29"
rel="12531044" target="_blank">JBERET-29</a> (Foreign
key constraint step_execution_jobexecutionid_fkey fails
when using Postgresql on WildFly, and we are trying to fix
it by jberet 1.0.0.Final. The problem happens when user
app starts a job within a transaction (e.g., CMT EJB),
jberet inserts JobExecution into database (thread 1 &
transaction 1), and then spawn a jberet-batch thread to
run the job (thead 2 & transaction 2). Sometimes T2
tries to access db before T1 is committed, hence the error
reported by the user.<br>
<br>
What's the common approach for solving this kind of
problem? I suppose other WildFly components may also have
this issue and probably already solved. Using transaction
synchronization is a cleaner solution than polling db, but
I'm not sure about its full implication. Ideally, I don't
want to use system level JTA API like TransactionManager
or Synchronization in jberet proper, but probably we can
implement it in WildFly jberet integration.<br>
<br>
Thanks,<br>
Cheng<br>
</div>
<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/wildfly-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>