[jbosscache-issues] [JBoss JIRA] Reopened: (JBCACHE-1470) Option to disable cache event generation for a cache operation.

Galder Zamarreno (JIRA) jira-events at lists.jboss.org
Wed Feb 4 11:50:44 EST 2009


     [ https://jira.jboss.org/jira/browse/JBCACHE-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Galder Zamarreno reopened JBCACHE-1470:
---------------------------------------



> Option to disable cache event generation for a cache operation.
> ---------------------------------------------------------------
>
>                 Key: JBCACHE-1470
>                 URL: https://jira.jboss.org/jira/browse/JBCACHE-1470
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Galder Zamarreno
>            Assignee: Galder Zamarreno
>             Fix For: 3.1.0.GA
>
>         Attachments: patch.txt
>
>
> For the prototype that I'm building for JBCACHE-816, I would like to implement a new Option that 
> disables generation of cache listener events for a particular cache operation.
> Why is that I want to implement this? First, bear in mind that currently, I'm trying to get a prototype
> done just by accessing the Cache interface (no SPI)
> Take this scenario:
> - Cluster 1 with nodes A, B and C.
> - Cluster 2 with nodes X, Y and Z.
> The idea of JBCACHE-816 is to enable inter cluster or data centre asynchronous replication of data.
> This service would be a singleton running in the coordinators of the the clusters that we're interconnecting.
> For this case, assume coord for C1 is A and coord for C2 is X.
> Both A and X start a new JGroups communication channel to pass each other node modification or 
> removal messages. The service is based around cache listeners where they listen to cache 
> modifications notifications and send it to the other node. For example:
> User puts data in A. Listener in A catches that, takes the modification and sends it over the JGroups channel
> to X which in turn needs to replicate it to the C2. To do that, it currently uses Cache API, so X calls put(...) on 
> the cache.
> I'd like to make communications be both way to give much greater flexibility to the solution, so when X calls 
> put(...) on the cache, it'll also receive notifications so you basically end up in an endless ping pong effect.
> The idea is for this put() call not to generate event notifications locally to avoid this ping pong effect.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the jbosscache-issues mailing list