[jira] Closed: (OPENJPA-88) Robustness of Distributed Cache Synchronization against transport outage

["Pinaki Poddar (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OPENJPA-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pinaki Poddar closed OPENJPA-88.
--------------------------------

    Resolution: Fixed

Gone by Patrick's suggestion.
transport outage is outside of OpenJPA's scope.

> Robustness of Distributed Cache Synchronization against transport outage
> ------------------------------------------------------------------------
>
>                 Key: OPENJPA-88
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-88
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: datacache
>            Reporter: Pinaki Poddar
>            Assignee: 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.
-
You can reply to this email to add a comment to the issue online.