Enthuware

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?

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.

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?

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.

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.

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.

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.

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.

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.

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().

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.