[wildfly-dev] Transaction synchronization between threads

Wed Feb 5 11:41:21 EST 2014

Yes. I don't think we should be suspending the transaction.

Stuart

On Wed, Feb 5, 2014 at 6:31 PM, James R. Perkins <jperkins at redhat.com>wrote:

>  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>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
>>
>
>
>
> _______________________________________________
> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://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/5ba69e97/attachment-0001.html 