Transaction synchronization between threads

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: CMT Batch Puzzle (Was Re: [Transaction synchronization between threads])

James Perkins
Ignore me, I think I misunderstood what the issue was. I was thinking a
long the lines of the job repository. Cheng explained it well here FWIW
https://java.net/projects/jbatch/lists/public/archive/2014-02/message/1.

The RI doesn't appear to do any kind of suspend/resume of transactions.
It just has it's own interface it uses and decides at runtime whether
it's SE using non-JTA or grabs it from JNDI on the container for EE.

On 02/04/2014 02:10 PM, James R. Perkins wrote:

>
> On 02/04/2014 01:31 PM, Jason Greene wrote:
>> On Feb 4, 2014, at 1:42 PM, James R. Perkins <[hidden email]>
>> wrote:
>>
>>> 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.
>> Good points; and this brings me to my pathological batch puzzle. What
>> does this code do:
>>
>> // Default gets transaction required
>> String doStuff() {
>>      long execID = jobOperator.start("simplejob", props);
>>      BatchStatus status =
>> jobOperator.getJobExecution(execID).getBatchStatus()
>>      while (status != COMMITTED && status != FAILED && status !=
>> ABANDONED) {
>>          Thread.sleep(1000);
>>      }
>>      return status.toString();
>> }
> Cheng will probably be better at answering as I'm still learning the
> spec better, but in general it will depend on what's defined in your
> simplejob.xml. For a JDBC repository it will perform an DB operations
> in a UserTransaction retrieved from the
> org.jboss.as.txn.service.TxnServices. This is the same UT that would
> be used for any transactions required in the batch job as well.
>
> For a in-memory repository, not transaction is used when updating the
> repository.
>
> Now what really happens with that code though is if it reaches one of
> those states fast enough you'll have an endless loop :P
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>

--
James R. Perkins
Red Hat JBoss Middleware

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Transaction synchronization between threads

Stuart Douglas
In reply to this post by jtgreene
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 <[hidden email]> wrote:

On Feb 4, 2014, at 3:51 PM, Radoslaw Rodak <[hidden email]> wrote:

> Hi
>
>
> Am 04.02.2014 um 22:16 schrieb Jason Greene <[hidden email]>:
>
>>
>> On Feb 4, 2014, at 3:13 PM, Jason Greene <[hidden email]> wrote:
>>
>>>
>>> On Feb 4, 2014, at 3:01 PM, James R. Perkins <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Transaction synchronization between threads

James Perkins
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 <[hidden email]> wrote:

On Feb 4, 2014, at 3:51 PM, Radoslaw Rodak <[hidden email]> wrote:

> Hi
>
>
> Am 04.02.2014 um 22:16 schrieb Jason Greene <[hidden email]>:
>
>>
>> On Feb 4, 2014, at 3:13 PM, Jason Greene <[hidden email]> wrote:
>>
>>>
>>> On Feb 4, 2014, at 3:01 PM, James R. Perkins <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
James R. Perkins
Red Hat JBoss Middleware

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Transaction synchronization between threads

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

Stuart


On Wed, Feb 5, 2014 at 6:31 PM, James R. Perkins <[hidden email]> 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 <[hidden email]> wrote:

On Feb 4, 2014, at 3:51 PM, Radoslaw Rodak <[hidden email]> wrote:

> Hi
>
>
> Am 04.02.2014 um 22:16 schrieb Jason Greene <[hidden email]>:
>
>>
>> On Feb 4, 2014, at 3:13 PM, Jason Greene <[hidden email]> wrote:
>>
>>>
>>> On Feb 4, 2014, at 3:01 PM, James R. Perkins <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
James R. Perkins
Red Hat JBoss Middleware


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Transaction synchronization between threads

jtgreene
Administrator
If we aren’t suspending the transaction though, then we also need consistent behavior of store type. The point of my puzzle post is that changing the store type should not alter the behavior of that code.

Also note that while this behavior *might* be more intuitive, its also more work, and it might eventually be in contradiction with the spec. Note IBM’s answer to a related question:
https://java.net/projects/jbatch/lists/public/archive/2014-02/message/2

On Feb 5, 2014, at 10:41 AM, Stuart Douglas <[hidden email]> wrote:

> Yes. I don't think we should be suspending the transaction.
>
> Stuart
>
>
> On Wed, Feb 5, 2014 at 6:31 PM, James R. Perkins <[hidden email]> 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 <[hidden email]> wrote:
>>
>> On Feb 4, 2014, at 3:51 PM, Radoslaw Rodak <[hidden email]> wrote:
>>
>> > Hi
>> >
>> >
>> > Am 04.02.2014 um 22:16 schrieb Jason Greene <[hidden email]>:
>> >
>> >>
>> >> On Feb 4, 2014, at 3:13 PM, Jason Greene <[hidden email]> wrote:
>> >>
>> >>>
>> >>> On Feb 4, 2014, at 3:01 PM, James R. Perkins <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>>
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> James R. Perkins
> Red Hat JBoss Middleware
>
>

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Transaction synchronization between threads

jtgreene
Administrator
Another thing to keep in mind is what happens if i have something like

for (Job job : jobs) {
    job.stop();
}
//Pause
for (Job job : jobs) {
    job.start();
}

return;

On Feb 5, 2014, at 10:44 AM, Jason Greene <[hidden email]> wrote:

> If we aren’t suspending the transaction though, then we also need consistent behavior of store type. The point of my puzzle post is that changing the store type should not alter the behavior of that code.
>
> Also note that while this behavior *might* be more intuitive, its also more work, and it might eventually be in contradiction with the spec. Note IBM’s answer to a related question:
> https://java.net/projects/jbatch/lists/public/archive/2014-02/message/2
>
> On Feb 5, 2014, at 10:41 AM, Stuart Douglas <[hidden email]> wrote:
>
>> Yes. I don't think we should be suspending the transaction.
>>
>> Stuart
>>
>>
>> On Wed, Feb 5, 2014 at 6:31 PM, James R. Perkins <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>> On Feb 4, 2014, at 3:51 PM, Radoslaw Rodak <[hidden email]> wrote:
>>>
>>>> Hi
>>>>
>>>>
>>>> Am 04.02.2014 um 22:16 schrieb Jason Greene <[hidden email]>:
>>>>
>>>>>
>>>>> On Feb 4, 2014, at 3:13 PM, Jason Greene <[hidden email]> wrote:
>>>>>
>>>>>>
>>>>>> On Feb 4, 2014, at 3:01 PM, James R. Perkins <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>>
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> James R. Perkins
>> Red Hat JBoss Middleware
>>
>>
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Transaction synchronization between threads

James Perkins
In reply to this post by jtgreene

On 02/05/2014 08:44 AM, Jason Greene wrote:
> If we aren’t suspending the transaction though, then we also need consistent behavior of store type. The point of my puzzle post is that changing the store type should not alter the behavior of that code.
Would using the suspend/resume now and changing to  synchronization
later be too big of a behavioral change?

 From what I can tell the RI does nothing here. I think the main issue
is using our JDBC repository. We insert records in a transaction which
is where the issue was initially seen. My gut tells me for now to use
the suspend/resume. Though I'd really like to do some more
reading/research on transactions. The spec is extremely vague on
anything EE related.

>
> Also note that while this behavior *might* be more intuitive, its also more work, and it might eventually be in contradiction with the spec. Note IBM’s answer to a related question:
> https://java.net/projects/jbatch/lists/public/archive/2014-02/message/2
>
> On Feb 5, 2014, at 10:41 AM, Stuart Douglas <[hidden email]> wrote:
>
>> Yes. I don't think we should be suspending the transaction.
>>
>> Stuart
>>
>>
>> On Wed, Feb 5, 2014 at 6:31 PM, James R. Perkins <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>> On Feb 4, 2014, at 3:51 PM, Radoslaw Rodak <[hidden email]> wrote:
>>>
>>>> Hi
>>>>
>>>>
>>>> Am 04.02.2014 um 22:16 schrieb Jason Greene <[hidden email]>:
>>>>
>>>>> On Feb 4, 2014, at 3:13 PM, Jason Greene <[hidden email]> wrote:
>>>>>
>>>>>> On Feb 4, 2014, at 3:01 PM, James R. Perkins <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>>
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> --
>> James R. Perkins
>> Red Hat JBoss Middleware
>>
>>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>

--
James R. Perkins
Red Hat JBoss Middleware

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Transaction synchronization between threads

Scott Marlow
On 02/05/2014 12:31 PM, James R. Perkins wrote:
>
> On 02/05/2014 08:44 AM, Jason Greene wrote:
>> If we aren’t suspending the transaction though, then we also need consistent behavior of store type. The point of my puzzle post is that changing the store type should not alter the behavior of that code.
> Would using the suspend/resume now and changing to  synchronization
> later be too big of a behavioral change?

IMO, Both behaviours could be supported via an extension property so
that applications can choose whether job creation is isolated or part of
the container managed transaction.

I don't know the non-EE batch systems but from a quick search, it looks
like both variations are in use out there.   (Quartz JDBC-JobStoreCMT vs
Spring which seems to expect that there is no active transaction when
creating a job).

>
>   From what I can tell the RI does nothing here. I think the main issue
> is using our JDBC repository. We insert records in a transaction which
> is where the issue was initially seen. My gut tells me for now to use
> the suspend/resume. Though I'd really like to do some more

IMO, there is no one way to handle this, some applications might expect
the job creation to be transactional and part of the CMT (especially if
the created job depends on the CMT ending successfully).  Some other
applications may expect to start jobs that are isolated from the CMT
(suspendTx/startJob/resumeTx should be fine for those applications).


> reading/research on transactions. The spec is extremely vague on
> anything EE related.
>>
>> Also note that while this behavior *might* be more intuitive, its also more work, and it might eventually be in contradiction with the spec. Note IBM’s answer to a related question:
>> https://java.net/projects/jbatch/lists/public/archive/2014-02/message/2
>>
>> On Feb 5, 2014, at 10:41 AM, Stuart Douglas <[hidden email]> wrote:
>>
>>> Yes. I don't think we should be suspending the transaction.
>>>
>>> Stuart
>>>
>>>
>>> On Wed, Feb 5, 2014 at 6:31 PM, James R. Perkins <[hidden email]> 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 <[hidden email]> wrote:
>>>>
>>>> On Feb 4, 2014, at 3:51 PM, Radoslaw Rodak <[hidden email]> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>>
>>>>> Am 04.02.2014 um 22:16 schrieb Jason Greene <[hidden email]>:
>>>>>
>>>>>> On Feb 4, 2014, at 3:13 PM, Jason Greene <[hidden email]> wrote:
>>>>>>
>>>>>>> On Feb 4, 2014, at 3:01 PM, James R. Perkins <[hidden email]> 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 <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>>
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> --
>>> James R. Perkins
>>> Red Hat JBoss Middleware
>>>
>>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12