Robustness of Distributed Cache Synchronization against transport outage
--------------------------------------------------------------------------
Key: OPENJPA-88
URL: http://issues.apache.org/jira/browse/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 outage.
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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
