openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pinaki Poddar (JIRA)" <>
Subject [jira] Created: (OPENJPA-88) Robustness of Distributed Cache Synchronization against transport outage
Date Tue, 12 Dec 2006 02:59:20 GMT
Robustness of Distributed Cache Synchronization against transport outage  

                 Key: OPENJPA-88
             Project: OpenJPA
          Issue Type: Improvement
          Components: datacache
            Reporter: Pinaki Poddar
         Assigned To: Pinaki Poddar

OpenJPA provides pluggable mechanism to synchronize L2 caches of remote OpenJPA runtime. The
commit events from one OpenJPA runtime can propagate to other remote OpenJPA runtime(s) on
native providers that use TCP or JMS as transport or third-party distributed caching providers
e.g. GemFire, Coherence etc. For native providers , specifically JMSRemoteCommitProvider,
currently do not cope with transport outage. For example, consider the following scenario:
1. a JMS topic T on which OpenJPA is publishing its cache change events becomes unavailable
2. naturally, the cache changes are not transmitted to remote caches are not communicated
to other caches during outage
3. JMS topic T becomes available again

At this point, it is natural to expect that OpenJPA should restore connection to the JMS transport
and continue transmitting commit changes. 

It is observed that OpenJPA does not restore connection and remains non-functional in the
above scenario. 

The primary issue here is to extend current implementation with robustness against transport

A related issue is: how to handle the commit events that occur during outage?
Two obvoius options are
a) Remember every event that occurs during outage. Transmit these events when the connection
is restored.
b) Do not remember the events during outage. Transmit events that occur after the connection
has been restored.

At this point, the suggestions/views on these options are welcome.   

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message