Topic
3 replies Latest Post - ‏2012-12-04T22:29:09Z by jhanders
mpickering1
mpickering1
5 Posts
ACCEPTED ANSWER

Pinned topic Getting Local BackingMaps to Update from Remote XC10

‏2012-12-03T23:40:27Z |
All,

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.

Scenario:

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.

Matt Pickering
Updated on 2012-12-04T22:29:09Z at 2012-12-04T22:29:09Z by jhanders
  • gissel
    gissel
    6 Posts
    ACCEPTED ANSWER

    Re: Getting Local BackingMaps to Update from Remote XC10

    ‏2012-12-04T00:12:59Z  in response to mpickering1
    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
      mpickering1
      5 Posts
      ACCEPTED ANSWER

      Re: Getting Local BackingMaps to Update from Remote XC10

      ‏2012-12-04T20:53:40Z  in response to gissel
      That fixed it. I wish this would be more obvious as this would be a common use case for distributed caching. Much appreciated!
      • jhanders
        jhanders
        6 Posts
        ACCEPTED ANSWER

        Re: Getting Local BackingMaps to Update from Remote XC10

        ‏2012-12-04T22:29:09Z  in response to mpickering1
        When you get the client side ObjectGrid using ObjectGridManager.getObjectGrid(ClientClusterContext), you should see a message stating the following:

        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.

        Jared Anderson