About Question enthuware.oce-ejbd.v6.2.427 :

Moderator: admin

Post Reply
Jofen
Posts: 9
Joined: Mon Oct 08, 2012 10:09 am
Contact:

About Question enthuware.oce-ejbd.v6.2.427 :

Post by Jofen »

For the explaination:
"As per section 18.4.3 of EJB 3.1 specification, if container-managed transaction demarcation is used and the REQUIRED or REQUIRES_NEW transaction attribute is specified or defaulted (Required or RequiresNew if the deployment descriptor is used), the container must begin a new transaction prior to invoking the timeout callback method."
Does Required transaction attribute also begin a new transaction?

admin
Site Admin
Posts: 10065
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.oce-ejbd.v6.2.427 :

Post by admin »

Jofen wrote:For the explaination:
"As per section 18.4.3 of EJB 3.1 specification, if container-managed transaction demarcation is used and the REQUIRED or REQUIRES_NEW transaction attribute is specified or defaulted (Required or RequiresNew if the deployment descriptor is used), the container must begin a new transaction prior to invoking the timeout callback method."
Does Required transaction attribute also begin a new transaction?
Yes, for the timer method.
HTH,
Paul.
If you like our products and services, please help us by posting your review here.

sanju.ait@gmail.com
Posts: 38
Joined: Fri Aug 16, 2013 11:37 pm
Contact:

Re: About Question enthuware.oce-ejbd.v6.2.427 :

Post by sanju.ait@gmail.com »

What is the reason that of this invocation atleast once if transaction is rolled back.

"If the transaction fails or is rolled back, the container must retry the timeout at least once." What is the purpose of this atleast once call?

himaiMinh
Posts: 358
Joined: Fri Nov 29, 2013 8:26 pm
Contact:

Re: About Question enthuware.oce-ejbd.v6.2.427 :

Post by himaiMinh »

if the transaction fails or is rolled back, the container must retry the timeout at least once.
Does it matter if the timer is persistent or not ?
I don't see the specification says this rule only applies to persistent timer.

admin
Site Admin
Posts: 10065
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.oce-ejbd.v6.2.427 :

Post by admin »

Section 8.2 says:"The timer service is intended for the modelling of long-lived business processes. Timers survive container crashes, server shutdown, and the activation/passivation and load/store cycles of the enterprise beans that are registered with them. These persistent guarantees can optionally be disabled on a per-timer basis."

So yes, if you disable these features they will not work otherwise, by default, all timers are persistent.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

himaiMinh
Posts: 358
Joined: Fri Nov 29, 2013 8:26 pm
Contact:

Re: About Question enthuware.oce-ejbd.v6.2.427 :

Post by himaiMinh »

So, does that means:
1. if the timer is persistent and transaction is rolled back, the container retry the timeout method at least once.
2. if the timer is non-persistent and transaction is rolled back, the container will not retry the timeout method
?


Regarding to transaction rolled back or failure, the spec does not explicitly say if the container will retry the timeout method of a non-persistent timer.

The spec only says in case of container crash/shut down, the timeout method will be retried at least once for persistent timer.

admin
Site Admin
Posts: 10065
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.oce-ejbd.v6.2.427 :

Post by admin »

himaiMinh wrote: The spec only says in case of container crash/shut down, the timeout method will be retried at least once for persistent timer.
Can you please tell me the section where it says this?
Paul.
If you like our products and services, please help us by posting your review here.

himaiMinh
Posts: 358
Joined: Fri Nov 29, 2013 8:26 pm
Contact:

Re: About Question enthuware.oce-ejbd.v6.2.427 :

Post by himaiMinh »

In session 18.4.3
Timer are persistent object(....). In the event of a container crash or shutdown, any single-event persistent timers that have expired during the intervening time before container restart must cause the corresponding timeout callback method to be invoked upon restart.....
In this quote, I am sure in case of container crash/shut down, non-persistent timer 's timeout method will not be invoked.

Second quote in the same session:
If the bean provider invokes the setRollbackOnly method from within the timeout callback method, the container must rollback the transaction in which the timeout callback method is invoked.... The container must retry the timeout after the transaction rollback.
In this second quote, it does not say whether the timer is persistent or non-persistent.
So, regardless the timer is persistent or non-persistent, when the transaction is rolled back, the container must retry the timeout after the transaction is rolled back.

admin
Site Admin
Posts: 10065
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.oce-ejbd.v6.2.427 :

Post by admin »

In your first quote, it clearly says that "Timers are persistent objects...". I didn't see any where in the spec where it talks about non-persistent timers.
Paul.
If you like our products and services, please help us by posting your review here.

himaiMinh
Posts: 358
Joined: Fri Nov 29, 2013 8:26 pm
Contact:

Re: About Question enthuware.oce-ejbd.v6.2.427 :

Post by himaiMinh »

On session 18.4.3
Timers are persistent object (unless explicitly created as non-persistent timers)
In the API of javax.ejb.Timer, there is a method public boolean isPersistent().

admin
Site Admin
Posts: 10065
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.oce-ejbd.v6.2.427 :

Post by admin »

Yes, you are right, the statement "the container must retry the timeout at least once" applies only in case of transaction failure or roll back irrespective of whether the timer is persistent or not.
Paul.
If you like our products and services, please help us by posting your review here.

Post Reply

Who is online

Users browsing this forum: No registered users and 71 guests