14.4. Remote Event Notification Framework
Prev | Chapter 14. Performance Pack | Next

## 14.4. Remote Event Notification Framework

The remote event notification framework allows a subset of the information available through Kodo JDO's transaction event system to be broadcast to remote listeners. The L2 data cache, for example, uses remote events to remain synchronized when deployed in multiple JVMs.

To enable remote events, you must configure the `PersistenceManagerFactory` to use a `RemoteCommitProvider` (see below). Given that a `RemoteCommitProvider` is properly configured, it is possible to register `RemoteCommitListener`s that will be alerted with a list of committed object ids whenever a transaction on a remote machine successfully commits.

### 14.4.1. Remote Commit Provider Configuration

Kodo JDO includes built in remote commit providers for JMS and TCP communication. The JMS remote commit provider can be configured by setting the `kodo.RemoteCommitProvider` to contain the appropriate configuration properties. The JMS provider understands the following properties:

- `Topic`: The topic that the remote commit provider should publish notifications to and subscribe to for notifications sent from other JVMs. Defaults to `topic/KodoCommitProviderTopic`

- `TopicConnectionFactory`: The JNDI name of a `javax.naming.TopicConnectionFactory` factory to use for finding topics. Defaults to `java:/ConnectionFactory`

To configure a `PersistenceManagerFactory` to use the JMS provider, your properties filename might look like the following:

Example 14.17. JMS Remote Commit Provider Configuration

    kodo.RemoteCommitProvider: jms(Topic=topic/KodoCommitProviderTopic)

| Note
Because of the nature of JMS, it is important that you invoke `PersistenceManagerFactory.close` when finished with a persistence manager factory. If you do not do so, a daemon thread will stay up in the JVM, preventing the JVM from exiting.

The TCP remote commit provider has several options that are defined as host specifications containing a host name or IP address and an optional port separated by a colon. For example, the host specification `saturn.solarmetric.com:1234` represents an `InetAddress` retrieved by invoking `InetAddress.getByName ("saturn.solarmetric.com")` and a port of 1234.

The TCP provider can be configured by setting the `kodo.RemoteCommitProvider` plugin property to contain the appropriate configuration settings. The TCP provider understands the following properties:

- `Port`: The TCP port that the provider should listen on for commit notifications. Defaults to 5636.

- `Addresses`: A semicolon-separated list of IP addresses to which notifications should be sent. No default value.

To configure a persistence manager factory to use the TCP provider, your properties filename might look like the following:

Example 14.18. TCP Remote Commit Provider Configuration

    kodo.RemoteCommitProvider: tcp(Addresses=10.0.1.10;10.0.1.11;10.0.1.12;10.0.1.13)

### 14.4.2. Customization

Additional mechanisms for remote event notification can be easily developed by creating an implementation of the `RemoteCommitProvider` interface, possibly by extending the `AbstractRemoteCommitProvider` abstract class. For details on particular customization needs, contact SolarMetric at jdosupport@solarmetric.com.

Prev | Up | Next
14.3. Datastore Cache | Home | 14.5. Fetch Groups