We are trying to integrate XC10 as a distributed cache for multiple application servers. We are storing objects in an ObjectGrid as a side cache via the Dynamic Map API in WXS. We are on 7.1.1 of WXS. We're noticing a disturbing issue when we trying to access cached data via two or more JVMs.
1. We insert an object into the cache in JVM 1. It can see the object.
2. We retrieve the object inserted by JVM 1 on JVM 2 by key name. We get the value.
3. We update the object on JVM 1 to a new value. JVM 1 sees the updated value.
4. We retrieve the object updated by JVM 1 on JVM 2. We get the OLD value.
Clearly the local BackingMap is acting as a local cache on both JVMs. What transaction settings or backing map values do we need to alter to get JVM 2 to see the same view of the cache as JVM 1. Ideally, I want both JVMs to always go to the XC10 remote cache and bypass local backing maps for any value retrieval. Is this done through the transaction isolation level, copy mode, lock strategy, etc?
I should note that I cannot programmatically override the ObjectGrid backing map settings since the ObjectGrid instance is initialized by the time we retrieve it for use. We are using transactions via the returned Session objects on the ObjectGrid instance but doesn't seem to matter.
Any help appreciated. We're scratching our heads with this as WXS with XC10 isn't behaving the way we expect a distributed cache to behave.
Pinned topic Getting Local BackingMaps to Update from Remote XC10
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-12-04T22:29:09Z at 2012-12-04T22:29:09Z by jhanders
gissel 2700039E0H6 Posts
Re: Getting Local BackingMaps to Update from Remote XC102012-12-04T00:12:59ZThis is the accepted answer. This is the accepted answer.It sounds like you might have the near cache enabled for the XC10 grid. Near cache is enabled by default if you use map whose name is the same as the grid name, e.g. grid is named A and using a map named A. The easiest way to disable the near cache is use a map which has a pessimistic lock strategy. This can be using a map named <gridName>.NONE.P. For instance, if the grid is named A then use a map named A.NONE.P. If you want to stick to a lock strategy of NONE, the default, then you can pro grammatically set the number of local buckets, disable near cache, as shown here: http://pic.dhe.ibm.com/infocenter/wdpxc/v2r1/index.jsp?topic=%2Fcom.ibm.websphere.datapower.xc.doc%2Frsimplecache.html
mpickering1 270002YVR05 Posts
Re: Getting Local BackingMaps to Update from Remote XC102012-12-04T20:53:40ZThis is the accepted answer. This is the accepted answer.
- gissel 2700039E0H
jhanders 1200009V3S6 Posts
Re: Getting Local BackingMaps to Update from Remote XC102012-12-04T22:29:09ZThis is the accepted answer. This is the accepted answer.
- mpickering1 270002YVR0
CWOBJ1128I: The client cache is enabled for maps <list of maps> on the <grid name> ObjectGrid.
This message indicates which maps have a near cache enabled. If you see this message for your map and you don't want to have a near cache enabled for it, you need to make sure your code to disable the near cache is correct or add the code if it doesn't exist.
I hope that helps give you a way to see it more obviously that you are caching on the client side and as a result can have stale data if you don't have an appropriate Evictor defined on the client side ObjectGrid or have the application logic to invalidate the near cache when appropriate.