users@ejb-spec.java.net

[ejb-spec users] [jsr345-experts] Re: TimerService.getAllTimers() (EJB_SPEC-47)

From: Marina Vatkina <marina.vatkina_at_oracle.com>
Date: Tue, 26 Jun 2012 18:05:47 -0700

We can use static int fields in the TimerService not to depend on Java
SE changes. If we do, we can use an overloaded getTimers method, passing
in a scope.

If you think we should support not only A) the search Scope (which can
be a Component - the default that would match no-arg option, a Module,
and an Application), but also B) the Runtime environment (an Instance or
a Cluster), the API should probably have another overloaded version with
2 arguments, though we would need to identify the default for the latter.

It's not clear to me if option (B) is that useful (and all of you voted
for 2b in the options below, i.e. cluster-wide search).

Should we do (A)?

If not, lets leave it as agreed upon originally - add getAllTimers()
that returns all active timers associated with the beans in the same EJB
module as the caller.

thanks,
-marina

Antonio Goncalves wrote:
> Well, I think this should belong to javax.naming really. A bit tough
> to get it in Java SE but it's just an enum of what already exists in
> JNDI (expect if we use Strings getAllTimers("app") but I don't like it)
>
> Antonio
>
> On Mon, Jun 25, 2012 at 10:00 PM, Marina Vatkina
> <marina.vatkina_at_oracle.com <mailto:marina.vatkina_at_oracle.com>> wrote:
>
> Which package/spec will Scope belong to? We don't want to define
> it in javax.ejb, correct?
>
> thanks,
> -marina
>
> Antonio Goncalves wrote:
>
> Instead of choosing between 1a & 1b, why don't we pass a scope
> as a parameter ? We have the JNDI scopes that we could mimic :
> comp, module, application, global... So why not having
> getAllTimers(Scope.Module) or getAllTimers(Scope.Application)
> ? If Java EE 7 is (at last) mentioning clustering in the spec,
> why not having an extra Cluster scope ?
> getAllTimers(Scope.Cluster) would return all the timers across
> the cluster.
> Antonio
>
> On Fri, Jun 22, 2012 at 3:48 PM, Jean-Louis MONTEIRO
> <jeanouii_at_gmail.com <mailto:jeanouii_at_gmail.com>
> <mailto:jeanouii_at_gmail.com <mailto:jeanouii_at_gmail.com>>> wrote:
>
> Marina,
>
> Yes, that is definitely useful.
> Being able to cancel a set of Timer spread on a cluster i don't
> necessary started, looks dangerous to me at first glance.
>
> That's why I choose 3b. Then, it means that it's just for
> information purpose if I don't own the Timer.
>
> Jean-Louis
>
>
>
> 2012/6/20 Marina Vatkina <marina.vatkina_at_oracle.com
> <mailto:marina.vatkina_at_oracle.com>
> <mailto:marina.vatkina_at_oracle.com
> <mailto:marina.vatkina_at_oracle.com>>>
>
>
> Returning to this item...
>
>
> Florent and Jean-Louis,
>
> Did you miss my question: "You chose 3b, so do you
> think that
> the new API is useful even if it is for information
> purpose only"?
>
>
> Experts, we still have an almost even split between 3a
> and 3b,
> so please cast your votes (if you don't think the new
> API is
> useful, please say so as well).
>
> thanks,
> -marina
>
>
> Marina Vatkina wrote:
>
> We have 2 votes for 3a and 2 votes for 3b.
>
> Those of you who didn't vote, please do so.
>
> Florent, Jean-Louis, (you chose 3b) do you still think
> that the new API is useful? What would in your
> opinion the
> caller be able to do with the timers returned by
> this API?
>
> thanks,
> -marina
>
> Florent BENOIT wrote:
>
> 1a
> 2b
> 3b
>
> Regards,
>
> Florent
>
> On 04/18/2012 11:01 PM, Marina Vatkina wrote:
>
> Experts,
>
> Do you think it is useful to add a method
> to the
> TimerService - getAllTimers() - (see
> http://java.net/jira/browse/EJB_SPEC-47)
> that will
> allow to get a collection of all active
> timers in
> this application?
>
> If you think it is useful, which options
> should be
> supported:
>
> 1. Scope
> a) All timers in the same EJB module
> b) All timers in the same application (EAR
> file)
>
> 2. Runtime:
> a) Timers from 1a or 1b running on the same
> server
> instance
> b) Timers from 1a or 1b running on any
> instance in
> the cluster
>
> 3. Cancelation:
> a) Timers returned by this method can be
> canceled
> by the caller (i.e. even if it doesn't own
> the timer)
> b) Only the bean that owns a timer can
> cancel it.
>
> If you think there is no need for the new API,
> please say so.
>
> Best,
> -marina
>
>
>
>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | Blog
> <http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Paris JUG
> <http://www.parisjug.org>
>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | Blog
> <http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Paris JUG <http://www.parisjug.org>