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

Galder Zamarreno (JIRA) jira-events at lists.jboss.org
Wed Jan 28 17:32:44 EST 2009


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

Galder Zamarreno updated JBCACHE-1470:
--------------------------------------

    Attachment: patch.txt


Please find attached a path for this issue. Note that this is the simplest 
solution which has a side effect:

Notifications for all registered listeners would be supresed for 
a cache invocation that uses this option. 

We could, if we want to, make this more explicit and for example pass
the class of the listener for which we want to supress notifications for this 
invocation. 

Maybe we could have both options.

Ideas/thoughts..etc welcome.

> 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