Thanks Manik.
My caches are geographically separated (UK, Japan, east and west coast US), so
I don't think shared cache loaders I going to work for me unless I do async
cache loader updates, and I'm pretty sure I don't want to do that.
The configuration I'm trying out has N gegraphically sepa
Will look into adding your tests, but for now:
1) This should pass - and it does on Branch_JBossCache_1_4_0 (off which
1.4.1.SP1 was recently released)
2) Changing the order with which you restart caches is a problem. There is no
way of knowing which cache's persistent state is "correct". T
"victor75" wrote : Thank you for the answer.
|
| I have one problematic scenario.
| There're two instances in my clustered environment: "serverA" and
"serverB", at the beginning both of them are alive.
| step 1. shutdown the "serverA"
| step 2. make a change in "serverB".
| step 3. s
Classic problem of replicated state being lost. By step 3, the entire cluster
is unavailable so all transient state is lost. This is why you have cache
loaders to persist the state somewhere so on restart this state is still
available to the cluster.
View the original post :
http://www.jbos
Thank you for the answer.
I have one problematic scenario.
There're two instances in my clustered environment: "serverA" and "serverB", at
the beginning both of them are alive.
step 1. shutdown the "serverA"
step 2. make a change in "serverB".
step 3. shutdown the "serverB"
step 4. start the "s
Yes, this makes a lot of sense. Perhaps you could use something like XStream
in your custom cache loader to serialize the objects to XML.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993961#3993961
Reply to the post :
http://www.jboss.com/index.html?modul
