Add externalid

[albfan]

https://issues.redhat.com/browse/EAPSUP-1336

Allow to define an external identificator for created timer

[tkburroughs]

This would of course require an update to the Jakarta Enterprise Beans specification, at least a move to 4.1.

A documentation update is needed to differentiate this new method from setInfo(Serializable info). Since it has "id" in the name, I'm guessing this might be intended to be used as a primary key in the database for persistent timers; if so, should there also be a new method on Timer to obtain the id? Should there be a new find method to search for a timer based on ID? Should there be a new attribute on @Schedule so an ID could be defined for automatic timers? What would be the effect on non-persistent timers?

[albfan]

Hi @tkburroughs this is to allow the app using EJB timers to identify it quickly.

id and timed_object_id from timer can be modified (like if a timer fails and needs to be recreated) so if an app creates a timer for something and needs to access this timer again (to modify or cancel) there're chances the timer referenced by initial id or timed_object_id doesn't exists anymore.

Right now the solution is to deserialize one by one all timers to looks for specific data to identify if timer exists or not

with this externalId, at the moment timer is created we have access to an external identifier (we can call it correlation key too) to find easily if timer exists or not.

Example:

An app creates a process called proc-1 that creates a timer alarm-1. For app proc-1_alarm-1 is an univoque reference for timer.

If we add this univoque reference to timer, we can search for this timer quickly if we need to manipulate it

[tkburroughs]

Applications already have this ability with Timer.getInfo(). When the timer is created, it could pass proc-1_alarm-1 as the user info, and then at any time it can call Timer.getInfo() to look for that value.

There is also a Timer.getHandle(), which returns a serializable reference to that timer, which an application could easily store somewhere and have very quick access to that timer in the future.

Just adding a new externalid doesn't seem to allow any quicker access; but I see you have now added a new method to TimerService to support this. However, couldn't the new method also just be TimerService.getTimersByInfo(java.io.Serializable info)... and thus work with the existing "info".

[albfan]

@tkburroughs yes, inside info, timer has this external id

Our app has a table indexing this id proc-1_alarm-1 and info bytearray. From it we get the id of timer and using getTimer(id) we find the timer. Since JBoss EAP 7.4.3, EJB timers check for that timer in database if it is not on memory.

But if that fails for any reason, when there're lot of timers, this operation is really slow.

getTimers() returns a list of timers in memory, and for each timer not having info in cache

            if (isClearTimerInfoCache(timerEntity)) {
                timerEntity.setCachedTimerInfo(Object.class);

it does a select info from jboss_ejb_timer where id =? that just timeout with lot of timers.

In app using timers, we have access to this id: proc-1_alarm-1 but not to info bytearray, that's why we ask for a query using the externalId. to easily find timers.

We understand the concern, "search by whatever", but external id seems a natural indexed data for a service used by other systems, like EJB timers. Info covers this in a real agnostic way, but with a poor performance access.

We are asking users to clean timers, and that might fix the problem, but still seems reasonable timer service to provide a quick search based on the external reference.