12:32 a.m.
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>wrote:
On Feb 4, 2014, at 3:51 PM, Radoslaw Rodak <rodakr(a)gmx.ch> wrote:
> Hi
>
>
> Am 04.02.2014 um 22:16 schrieb Jason Greene <jason.greene(a)redhat.com>:
>
>>
>> On Feb 4, 2014, at 3:13 PM, Jason Greene <jason.greene(a)redhat.com>
wrote:
>>
>>>
>>> On Feb 4, 2014, at 3:01 PM, James R. Perkins <jperkins(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev