-1
This item couples the timer service to a specific persistence mechanism
(JDBC data sources) and further, assumes a single table will be used. Even
though most vendors likely use JDBC+RDB for persistent timers, I don't
think this should be required by the specification.
-Jeremy
From: Marina Vatkina <marina.vatkina_at_oracle.com>
To: jsr345-experts_at_ejb-spec.java.net,
Date: 07/24/2012 05:08 PM
Subject: [jsr345-experts] EJB_SPEC-45: Define standard way to
configure where timers are persisted
Experts,
Please take a look at
http://java.net/jira/browse/EJB_SPEC-45.
To add this functionality to the spec, it will mean the following:
1. Support for using EJB Timer Service with more than one resource or
table name in the same application server instance for storing the
timers is out of the scope and is not portable. If an application is
requesting a resource or a table name that cannot be satisfied, it will
be rejected by the container.
2. The following deployment descriptor configuration can be used to
configure the resource and the table name for the EJB Timer Service:
<timer-service>
<data-source-lookup>java:global/jdbc/myDs</data-source-lookup>
<table>EJB_TIMER_TABLE</table>
</timer-service>
The <data-source-lookup> value can be a java:global JNDI name or a
container-specific JNDI name of the resource to be used to store
persistence timers. If not specified, the container uses its own
predefined resource.
The <table> value is the table name to be used to store persistence
timers. If not specified, the container chooses a table name to be used.
3. The TimerServiceConfig annotation can be used on a bean class with a
timeout callback method as following (see #1 above for the limitations):
@javax.ejb.TimerServiceConfig(dataSourceLookup="java:global/jdbc/myDs",
table="EJB_TIMER_TABLE")
The attributes of the annotation follow the same rules as that of the
deployment descriptor.
Let me know if you see a problem with the proposal.
thanks,
-marina