JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server 3.1 Application Development Guide
search filter icon
search icon

Document Information

Preface

Part I Development Tasks and Tools

1.  Setting Up a Development Environment

2.  Class Loaders

3.  Debugging Applications

Part II Developing Applications and Application Components

4.  Securing Applications

5.  Developing Web Services

6.  Using the Java Persistence API

7.  Developing Web Applications

8.  Using Enterprise JavaBeans Technology

Value Added Features

Read-Only Beans

The pass-by-reference Element

Pooling and Caching

Pooling Parameters

Caching Parameters

Priority Based Scheduling of Remote Bean Invocations

Immediate Flushing

EJB Timer Service

To Deploy an EJB Timer to a Cluster

Using Session Beans

About the Session Bean Containers

Stateless Container

Stateful Container

Stateful Session Bean Failover

Choosing a Persistence Store

Enabling Checkpointing

Specifying Methods to Be Checkpointed

Session Bean Restrictions and Optimizations

Optimizing Session Bean Performance

Restricting Transactions

EJB Singletons

Using Read-Only Beans

Read-Only Bean Characteristics and Life Cycle

Read-Only Bean Good Practices

Refreshing Read-Only Beans

Invoking a Transactional Method

Refreshing Periodically

Refreshing Programmatically

Deploying Read-Only Beans

Using Message-Driven Beans

Message-Driven Bean Configuration

Connection Factory and Destination

Message-Driven Bean Pool

Domain-Level Settings

Message-Driven Bean Restrictions and Optimizations

Pool Tuning and Monitoring

The onMessage Runtime Exception

9.  Using Container-Managed Persistence

10.  Developing Java Clients

11.  Developing Connectors

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

17.  Using the Java Message Service

18.  Using the JavaMail API

Index

EJB Timer Service

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.

Minimum Delivery Interval

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.

Maximum Redeliveries

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.

Redelivery Interval

Specifies how long in milliseconds the EJB timer service waits after a failed ejbTimeout delivery before attempting a redelivery. The default is 5000.

Timer DataSource

Specifies the database used by the EJB Timer Service. The default is jdbc/__TimerPool.


Caution

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.

To Deploy an EJB Timer to a Cluster

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

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.


  1. Execute the following command:
    asadmin set configs.config.cluster_name-config.ejb-container.ejb-timer-service.timer-
    datasource=jdbc/my-timer-resource
  2. Restart the DAS and the target cluster(s).
    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.