Adding some JIRA links to this thread for future ref:
1. IgnoreModifications was designed for use when you chain cache loaders. See
JBCACHE-751 for getting this to work on individual cache loaders.
2. I've created a feature request for being able to use a ClusteredCacheLoader
with
Ok had a look into
| !-- determines whether this cache loader ignores writes - defaults to
false. --
| ignoreModificationstrue/ignoreModifications
|
|
and what it can and cant do.
Here is the config i used
| mbean code=org.jboss.cache.loader.tcp.TcpCacheServer
lovelyliatroim wrote :
| anonymous wrote :
| | From your description, it sounds like you might want to use LOCAL cache
mode and a TCPCacheLoader. Have you looked into that?
| |
|
| I have read about it but the thing that i dont want is that when you add an
entry into one of the
Yep both sets of code snippets work. No replication being done.
Super stuff Brian, thanks alot.
anonymous wrote :
| From your description, it sounds like you might want to use LOCAL cache
mode and a TCPCacheLoader. Have you looked into that?
|
I have read about it but the thing that i
great
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4109536#4109536
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4109536
___
jboss-user mailing list
jboss-user@lists.jboss.org
From your description, it sounds like you might want to use LOCAL cache mode
and a TCPCacheLoader. Have you looked into that?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4109427#4109427
Reply to the post :
anonymous wrote : Re: your loop:
|
| root.addChild(path) is a cache write. You have to setCacheModeLocal(true)
before anything that changes the state of the cache if you want to avoid any
replication.
Still replicates even if i have it before it.
View the original post :
How about this?
| for(int i = 0; i noOfItems;i++) {
| Quote quote1 = new Quote(nodeName+requestCounter,EWX,EUR);
| String path = /quotes/+quote1.getTreePath();
| cache.getInvocationContext().getOptionOverrides().setCacheModeLocal(true);
| cache.put(Fqn.fromString(path), quote,
Ok seeking some clarity on why you would use a ClusteredCacheLoader in my case.
I have seen the thread
http://www.jboss.org/index.html?module=bbop=viewtopict=118598
but in terms of my needs ;).
Ok running my cache in invalidation mode is a no go for me, i dont want data
evicted if i update a
anonymous wrote : Perhaps run in replicated mode but for every write set a
cacheModeLocal Option?
Kinda worked but not really, first put was surpressed i.e not replicated but
the rest after it were. Im adding the nodes like so
| for(int i = 0; i noOfItems;i++){
|
Just to correct my last post, it is misleading.
The first one was suppressed and the rest wasnt. I played around with the
placing of setCacheModeLocal and what i discovered was that it doesnt replicate
the first one when i have code like this (not shown in first snippet because i
didnt think
anonymous wrote :
| replication with buddy replication: This is where i am not so clear, im not
so clear on how buddy replication works, i have set it up but dont know the
reasoning behind why it does what it does. Ok i would have thought that you
would share data with your buddy and the
So now im left asking myself what the hell is ClusteredCacheLoader used for??
Doesnt make sense to use it with a replicated cache, you could use it with
invalidation and you cant use it with a local cache.
Then i come across this
http://www.jboss.org/index.html?module=bbop=viewtopict=118598
2
Re: your loop:
root.addChild(path) is a cache write. You have to setCacheModeLocal(true)
before anything that changes the state of the cache if you want to avoid any
replication.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4108939#4108939
Reply to the
I will hazard a guess and say this is the route of my problem
anonymous wrote :
| Local caches don't join a cluster and don't communicate with other caches
in a cluster. Therefore their elements don't need to be serializable - however,
we recommend making them serializable, enabling a user
You are correct, this has to do with a JGroups channel not being opened. Not
much you can do, I'm afraid, except perhaps run in replicated mode and then
remove the replication interceptor. :-/
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4108734#4108734
Perhaps run in replicated mode but for every write set a cacheModeLocal Option?
E.g.:
| cache.getInvocationContext().getOptionOverrides().setCacheModeLocal(true);
| cache.put(fqn, key, value);
|
View the original post :
Ok thanks guys, dont have the time at the moment to dig deeper, just assessing
at top level what can and cant be done. We thought we could use the cache
standalone and also use what the ClusteredCacheLoader has to offer.
thanks for input,
LL
View the original post :
18 matches
Mail list logo
