Re: [wildfly-dev] Transaction synchronization between threads

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(a)redhat.com&gt;wrote: > > On Feb 4, 2014, at 3:51 PM, Radoslaw Rodak <rodakr(a)gmx.ch&gt; wrote: > > > Hi > > > > > > Am 04.02.2014 um 22:16 schrieb Jason Greene <jason.greene(a)redhat.com&gt;: > > > >> > >> On Feb 4, 2014, at 3:13 PM, Jason Greene <jason.greene(a)redhat.com&gt; > wrote: > >> > >>> > >>> On Feb 4, 2014, at 3:01 PM, James R. Perkins <jperkins(a)redhat.com&gt; > 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(a)redhat.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing listwildfly-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev -- James R. Perkins Red Hat JBoss Middleware