[wildfly-dev] Transaction synchronization between threads
James R. Perkins
jperkins at redhat.com
Wed Feb 5 11:31:36 EST 2014
You're suggesting something more like
TransactionManager.getTransaction().registerSynchronization(synchronization);
Rather than the;
TransactionManager.suspend();
try {
doStuff();
} finally {
TransactionManager.resume();
}
Am I understanding that correctly?
On 02/04/2014 10:32 PM, Stuart Douglas wrote:
> 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.
>
> The way this is accomplished is two fold:
> - 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)
> - Timers are not actually started or cancelled until the
> afterComplete() synchronization runs.
>
> 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.
>
> Stuart
>
>
> On Tue, Feb 4, 2014 at 11:53 PM, Jason Greene <jason.greene at redhat.com
> <mailto:jason.greene at redhat.com>> wrote:
>
>
> On Feb 4, 2014, at 3:51 PM, Radoslaw Rodak <rodakr at gmx.ch
> <mailto:rodakr at gmx.ch>> wrote:
>
> > Hi
> >
> >
> > Am 04.02.2014 um 22:16 schrieb Jason Greene
> <jason.greene at redhat.com <mailto:jason.greene at redhat.com>>:
> >
> >>
> >> On Feb 4, 2014, at 3:13 PM, Jason Greene
> <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
> >>
> >>>
> >>> On Feb 4, 2014, at 3:01 PM, James R. Perkins
> <jperkins at redhat.com <mailto:jperkins at redhat.com>> wrote:
> >>>
> >>>>
> >>>> On 02/04/2014 12:40 PM, Scott Marlow wrote:
> >>>>> On 02/04/2014 02:42 PM, James R. Perkins wrote:
> >>>>>>
> >>>>>> On 02/04/2014 08:16 AM, Jason Greene wrote:
> >>>>>>> On Feb 4, 2014, at 9:56 AM, Cheng Fang <cfang at redhat.com
> <mailto:cfang at redhat.com>> wrote:
> >>>>>>>
> >>>>>>>> On 2/4/14, 9:57 AM, Stuart Douglas wrote:
> >>>>>>>>> I would use a transaction synchronization, so you don't
> spawn the other thread until the transaction is successfully
> committed.
> >>>>>>>>>
> >>>>>>>> yes, we could implement it in wildfly-batch integration
> module.
> >>>>>>>>> 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.
> >>>>>>>> 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:
> >>>>>>>>
> >>>>>>>> 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:
> >>>>>>>>
> >>>>>>>> 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.
> >>>>>>> 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.
> >>>>>> I don't see in the spec where it requires any kind of
> transaction around
> >>>>>> a job repository. In fact the spec states "Note the
> implementation of
> >>>>>> the job repository is outside the scope of this
> specification.".
> >>>>>>
> >>>>>> The RI does have a JDBC repository, but it doesn't insert
> anything into
> >>>>>> the tables in a transaction.
> >>>>>>
> >>>>>> If we're only seeing this in PostgreSQL and a workaround
> with putting
> >>>>>> JobOperator.start() outside a transaction works, I would
> suggest that's
> >>>>>> okay for now. I do agree it needs to be fixed, but we might
> want to look
> >>>>>> at how we're handling transaction in JBeret as a whole. The
> RI, not that
> >>>>>> I want to model anything after it, uses it's own
> >>>>>> TransactionManagerAdapter. It might make sense for JBeret
> to use a
> >>>>>> TransactionManager rather than a UserTransaction. Or put
> the ownness on
> >>>>>> the SPI implementation of the BatchEnvironment to handle
> the transactions.
> >>>>>
> >>>>> 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?
> >>>> 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 ;)
> >>>
> >>> That would be silly :)
> >>
> >> Requiring a NOT_SUPPORTED method that is. It's pretty easy for
> JBeret to isolate the transaction if it wanted to
> >>
> >> tx = TransactionManager.suspend()
> >> TransactionManager.begin()
> >> // write the record
> >> TransactionManager.commit()
> >> TransactionManager.resume(tx);
> >>
> >
> > What will happened to suspended Transaction when you get
> Exception on TransactionManager.commit() ?
>
> You put resume in a finally block. Just like RequiresNew
> effectively does.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
Red Hat JBoss Middleware
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140205/0810debc/attachment.html
More information about the wildfly-dev
mailing list