[wildfly-dev] Transaction synchronization between threads

[Stuart Douglas]

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>wrote:

>
> On Feb 4, 2014, at 3:51 PM, Radoslaw Rodak <rodakr at gmx.ch> wrote:
>
> > Hi
> >
> >
> > Am 04.02.2014 um 22:16 schrieb Jason Greene <jason.greene at redhat.com>:
> >
> >>
> >> On Feb 4, 2014, at 3:13 PM, Jason Greene <jason.greene at redhat.com>
> wrote:
> >>
> >>>
> >>> On Feb 4, 2014, at 3:01 PM, James R. Perkins <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> 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
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140205/f81e0360/attachment-0001.html