Part I Development Tasks and Tools
1. Setting Up a Development Environment
Part II Developing Applications and Application Components
6. Using the Java Persistence API
7. Developing Web Applications
8. Using Enterprise JavaBeans Technology
Priority Based Scheduling of Remote Bean Invocations
About the Session Bean Containers
Stateful Session Bean Failover
Specifying Methods to Be Checkpointed
Session Bean Restrictions and Optimizations
Optimizing Session Bean Performance
Read-Only Bean Characteristics and Life Cycle
Invoking a Transactional Method
Message-Driven Bean Configuration
Connection Factory and Destination
Message-Driven Bean Restrictions and Optimizations
The onMessage Runtime Exception
9. Using Container-Managed Persistence
12. Developing Lifecycle Listeners
13. Developing OSGi-enabled Java EE Applications
Part III Using Services and APIs
14. Using the JDBC API for Database Access
15. Using the Transaction Service
16. Using the Java Naming and Directory Interface
The EJB Timer Service uses a database to store persistent information about EJB timers. The EJB Timer Service in GlassFish Server is preconfigured to use an embedded version of the Java DB database.
The EJB Timer Service configuration can store persistent timer information in any database supported by the GlassFish Server for persistence. For a list of the JDBC drivers currently supported by the GlassFish Server, see the Oracle GlassFish Server 3.1-3.1.1 Release Notes. For configurations of supported and other drivers, see Configuration Specifics for JDBC Drivers in Oracle GlassFish Server 3.1 Administration Guide.
The timer service is automatically enabled when you deploy an application or module that uses it. You can verify that the timer service is running by accessing the following URL:
http://localhost:8080/ejb-timer-service-app/timer
To change the database used by the EJB Timer Service, set the EJB Timer Service’s Timer DataSource setting to a valid JDBC resource. If the EJB Timer Service has already been started in a server instance, you must also create the timer database table. DDL files are located in as-install/lib/install/databases.
Using the EJB Timer Service is equivalent to interacting with a single JDBC resource manager. If an EJB component or application accesses a database either directly through JDBC or indirectly (for example, through an entity bean’s persistence mechanism), and also interacts with the EJB Timer Service, its data source must be configured with an XA JDBC driver.
You can change the following EJB Timer Service settings. You must restart the server for the changes to take effect.
Specifies the minimum time in milliseconds before an expiration for a particular timer can occur. This guards against extremely small timer increments that can overload the server. The default is 1000.
Specifies the maximum number of times the EJB timer service attempts to redeliver a timer expiration after an exception or rollback of a container-managed transaction. The default is 1.
Specifies how long in milliseconds the EJB timer service waits after a failed ejbTimeout delivery before attempting a redelivery. The default is 5000.
Specifies the database used by the EJB Timer Service. The default is jdbc/__TimerPool.
Caution - Do not use the jdbc/__TimerPool resource for timers in clustered GlassFish Server environments. You must instead use a custom JDBC resource or the jdbc/__default resource. See the instructions below, in To Deploy an EJB Timer to a Cluster. Also refer to Enabling the jdbc/__default Resource in a Clustered Environment in Oracle GlassFish Server 3.1 Administration Guide. |
For information about the asadmin list-timers and asadmin migrate-timers subcommands, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual. For information about migrating EJB timers, see Migrating EJB Timers in Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide.
You can use the --keepstate option of the asadmin redeploy command to retain EJB timers between redeployments.
The default for --keepstate is false. This option is supported only on the default server instance, named server. It is not supported and ignored for any other target.
When the --keepstate is set to true, each application that uses an EJB timer is assigned an ID in the timer database. The EJB object that is associated with a given application is assigned an ID that is constructed from the application ID and a numerical suffix. To preserve active timer data, GlassFish Server stores the application ID and the EJB ID in the timer database. To restore the data, the class loader of the newly redeployed application retrieves the EJB timers that correspond to these IDs from the timer database.
For more information about the asadmin redeploy command, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.
This procedure explains how to deploy an EJB timer to a cluster.
By default, the GlassFish Server 3.1 timer service points to the preconfigured jdbc/__TimerPool resource, which uses an embedded Java DB (Derby) database configuration that will not work in clustered environments.
The problem is that embedded Java DB runs in the GlassFish Server Java VM, so when you use the jdbc/__TimerPool resource, each DAS and each clustered server instance will have its own database table. Because of this, clustered server instances will not be able to find the database table on the DAS, and the DAS will not be able to find the tables on the clustered server instances.
The solution is to use either a custom JDBC resource or the jdbc/__default resource that is preconfigured but not enabled by default in GlassFish Server. The jdbc/__default resource does not use embedded Java DB by default.
Before You Begin
If creating a new timer resource, the resource should be created before deploying applications that will use the timer.
Caution - Do not use the jdbc/__TimerPool resource for timers in clustered GlassFish Server environments. You must instead use a custom JDBC resource or the jdbc/__default resource. See Enabling the jdbc/__default Resource in a Clustered Environment in Oracle GlassFish Server 3.1 Administration Guide. |
asadmin set configs.config.cluster_name-config.ejb-container.ejb-timer-service.timer- datasource=jdbc/my-timer-resource
asadmin stop-cluster cluster-name asadmin stop-domain domain-name asadmin start-domain domain-name asadmin start-cluster cluster-name
Troubleshooting
If you inadvertently used the jdbc/__TimerPool resource for your EJB timer in a clustered GlassFish Server environment, the DAS and the clustered server instances will be using separate Java DB database tables that are running in individual Java VMs. For timers to work in a clustered environment, the DAS and the clustered server instances must share a common database table.
If you attempt to deploy an application with EJB timers without setting the timer resource correctly, the startup will fail, and you will be left with a marker file, named ejb-timer-service-app, on the DAS that will prevent the Timer Service from correctly creating the database table.
The solution is to remove the marker file on the DAS, restart the DAS and the clusters, and then redploy any applications that rely on the offending EJB timer. The marker file is located on the DAS in as-install-parent/glassfish/domains/domain-name/generated/ejb/ejb-timer-service-app.