So one last question.

If I want to use another quartz scheduler, other than TomEE's default, in
the same DBMS schema, is it ok to just use those classes from
org.apache.openejb.quartz? (of course, adding quartz jars again will
probably be a bad idea, I guess)



[]

Leo

On Sat, Oct 18, 2014 at 11:31 AM, Leonardo K. Shikida <shik...@gmail.com>
wrote:

> Hi Romain
>
> Actually, I've just read the spec again (JSR318, chap 18) and I think it
> does not say anything about this regardless the persistence :-)
>
> It simply says nothing about if multiple triggers for the same EJB that
> share the same ScheduleExpression are treated separately or not. Although,
> since each timer may have its "info" serializable field, my feeling was
> that each timer should be considered an independent entity. But this is
> opinion, not spec.
>
>
> []
>
> Leo
>
> On Sat, Oct 18, 2014 at 11:19 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
>
>> Spec doesnt say/mandate anything when it comes to persistence
>> Le 18 oct. 2014 15:38, "Leonardo K. Shikida" <shik...@gmail.com> a écrit
>> :
>>
>> > Hi Romain
>> >
>> > I think... I am getting the idea :-)
>> >
>> > From your answer, I infer that if a have a bean with some method
>> annotated
>> > with @Timeout then "task" = execute this method.
>> >
>> > And each "task" has a single "trigger". So, if I try to create a new
>> > "trigger" for this "task", I will end up just replacing the existent
>> > "trigger" (or if it has the same cron expression, just being ignored).
>> > Persistent, of course.
>> >
>> > I thought that if I create 3 triggers for the same task to be run at the
>> > same time, then the task would be executed 3 times (one for each
>> trigger).
>> >
>> > I really don't know what the spec talks about this (if it talks about
>> it).
>> >
>> > What's fancy about this IMO is that this 1-1 relationship between
>> triggers
>> > and beans is clear when we're creating timers statically, using
>> annotations
>> > (@Schedule), but it wasn't clear for me for dynamically created timers
>> > (Timer created = timerService.createCalendarTimer(exp,config))
>> >
>> >
>> >
>> > []
>> >
>> > Leo
>> >
>> > On Sat, Oct 18, 2014 at 10:23 AM, Romain Manni-Bucau <
>> > rmannibu...@gmail.com>
>> > wrote:
>> >
>> > > Le 18 oct. 2014 14:47, "Leonardo K. Shikida" <shik...@gmail.com> a
>> > écrit :
>> > > >
>> > > > > "hello 1413583260198" was created in a previous attempt, so my
>> > feeling
>> > > is
>> > > >
>> > > > > that, somehow, even creating a new timer on every server restart,
>> > tomEE
>> > > (or
>> > > > > Quartz) is assuming that the calendar timer is already created
>> > > (checking by
>> > > > > cron expression maybe?). In fact, in the DB, there are only 3
>> > triggers
>> > > > > everytime.
>> > > > > >
>> > > > > >
>> > > > >
>> > > > > If persistent that s possible
>> > > > >
>> > > > >
>> > > > Hi Romain
>> > > >
>> > > > Yeah, but then is it a bug? I mean, if I am creating a new timer,
>> even
>> > if
>> > > > it has the same calendar cron expression, it should not be silently
>> > > ignored
>> > > > just because there's already one in the DB, right?
>> > > >
>> > >
>> > > If that s the same for the same bean with same data it doesnt shock
>> me.
>> > If
>> > > not persistence adapter id maybe needs some tweak
>> > >
>> > > > Yes, it's persistent. It has to be to make quartz cluster work.
>> > > >
>> > > > */5 no?
>> > > > >
>> > > > >
>> > > > sorry, I feel so stupid about this :-)
>> > > >
>> > > > TIA
>> > > >
>> > > > Leo
>> > >
>> >
>>
>
>

Reply via email to