timer session start

[tom.baeyens]

there was a timerSession.start invoked by the timer session binding

i didn't understand the purpose, so i removed it.

it didn't break any tests so that is already a good indication that it can be removed :-)

[pascal.verdage]

Hi,

The method start registers a listener on the environment in order to wake up the JobExecutor after the commit, when the timers have been registered into the database.
It was called at the creation of the service to be sure to wake up the jobExecutor at the end of the transaction not to miss a timer firing.

I replaced this by the notification used in messages and a boolean to signal only once the jobExecutor.

Regards,
Pascal

[tom.baeyens]

"pascal.verdage" wrote:
I replaced this by the notification used in messages and a boolean to signal only once the jobExecutor.

[pascal.verdage]

Hi,

I suppose you expect some explanations. I meant that the call in the binding of a method to create a listener is replaced by the creation of the listener when a timer is scheduled.

Regards,
Pascal

[aguizar]

Pascal, so instead of notifying the job executor as many times as timers are created, you just notify once? What happens in case no timers are created?

I ask because I want the enterprise messages/timers to resemble the job executor as much as possible.

[tom.baeyens]

alejandro,

i already fixed it.

this is about 2 things that don't have a counterpart in ejb timers:

* when the server boots, the ejb timer facility should start automatically. in the case of the job executor, it should be declared as init="eager" so that it's started immediately when the environment factory is created.

* when an ejb timer is created, it's the responsibility of the ejb timer facility to execute them. the ejb timer facility doesn't need notification. the job executor does need notification in case it is inbetween polls.