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 RemoteCommitListeners that will be alerted with a list of committed object ids whenever a transaction on a remote machine successfully commits.
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.jms.TopicConnectionFactory factory to use for finding topics. Defaults to java:/ConnectionFactory. This setting may vary depending on the application server in use; consult the application server's documentation for details of the default JNDI name for the javax.jms.TopicConnectionFactory instance. For example, under Weblogic, the JNDI name for the TopicConnectionFactory is "javax.jms.TopicConnectionFactory".
ExceptionReconnectAttempts: The number of times to attempt to reconnect if the JMS system notifies Kodo of a serious connection error. Defaults to 0, meaning Kodo will log the error but otherwise ignore it, hoping the connection is still valid.
*: All other configuration properties will be interpreted as settings to pass to the JNDI InitialContext on construction. For example, you might set the java.naming.provider.url property to the URL of the context provider.
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]](img/note.gif) | 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:
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.