[ http://issues.apache.org/jira/browse/OPENJPA-88?page=comments#action_12458727 ] Patrick Linskey commented on OPENJPA-88: ----------------------------------------
> 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. I think that OpenJPA should not attempt to do any outage detetection / buffering. Rather, QoS issues such as this should be the responsibility of the JMS implementation. > 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
