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 >
