Returning to this thread for more clarifications.
1. Distributing non-persistent timers? Does any of your implementations
support non-persistent timers to be invoked on another JVM?
Section "13.2.3 Non-persistent Timers" defines them as:
"A non-persistent timer is a timer whose lifetime is tied to the JVM in
which it is created."
If nobody objects, I'll remove non-persistent timers from the statement
below.
2. Non-persistent timers returned by getTimers() and getAllTimers().
I plan to add to both descriptions:
"Non-persistent timers returned by this method include only timers
created in the same JVM in which the method is being executed."
-marina
Marina Vatkina wrote:
> I had added this text at the bottom of the p.322 in the EDR (as part
> of various clarifications):
>
> "The timeout callback method for a programmatically created persistent
> or non-persistent timer will be invoked on the JVM on which the timer
> was created. In the event of a container crash or container shutdown,
> the timeout callback method for a programmatically created persistent
> timer that has not been cancelled will be invoked on a new JVM when
> the container is restarted or on another JVM instance across which the
> container is distributed."
>
> If you think it needs to be expanded, please suggest your version or
> the extra text.
>
> thanks,
> -marina
>
> Reza Rahman wrote:
>> +1
>>
>> On 5/3/2012 1:33 AM, Adam Bien wrote:
>>> Hi *,
>>>
>>> given persistent timers are coordinated in a shared DB, they should
>>> work-out-of the box in a cluster. It means: a timer should fire on a
>>> node, but not all nodes at the same time.
>>>
>>> It is one of the FAQs. Should we clarify that (or the supposed
>>> behavior) in the spec?
>>>
>>> thanks!,
>>>
>>> adam
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2012.0.1913 / Virus Database: 2425/4974 - Release Date:
>>> 05/02/12
>>>
>>>
>>>
>>
>