Topic
7 replies Latest Post - ‏2012-09-14T19:58:21Z by SystemAdmin
SystemAdmin
SystemAdmin
1485 Posts
ACCEPTED ANSWER

Pinned topic Loader behavior with containsKey

‏2012-08-21T19:34:22Z |
In order to distinguish a key with a null value vs a key that does not exist in the map, each get to my object map first calls containsKey as suggested in the API documentation. This works fine for maps that do not use a loader. When using a loader I noticed that the contains key actually calls back to the loader to see if the data store contains the key. It looks like the containsKey method calls the same get method on the loader that a get on the object map calls. This means that for each of my get calls on the object map (which first calls containsKey and then get) the loader is being called twice. Is there a way to distinguish in the Loader a containsKey call vs a get call? Is there a way to leverage the work from the containsKey call so the data is loaded into the cache and the objectMap.get does not have to call the loader again? Is there some other recommended way to prevent the loader from being called twice in this scenario?
Updated on 2012-09-14T19:58:21Z at 2012-09-14T19:58:21Z by SystemAdmin
  • joshuawhite929
    joshuawhite929
    52 Posts
    ACCEPTED ANSWER

    Re: Loader behavior with containsKey

    ‏2012-09-11T13:02:17Z  in response to SystemAdmin
    Still looking for an answer on this. As James mentions, a call to myObjectMap.containsKey(someKey) will fire the loader if the data is not in the grid. This behavior is expected. What I am concerned with is that a subsequent call to myObjectMap.get(someKey) will also fire the loader as if the call to "contains" key didn't store its data into the grid.

    This behavior is troubling if the loader invocation is expensive. We would like to better understand if this behavior is a result of a misconfiguration on our part or a feature of WXS.

    Thanks,

    Joshua
  • SystemAdmin
    SystemAdmin
    1485 Posts
    ACCEPTED ANSWER

    Re: Loader behavior with containsKey

    ‏2012-09-13T13:39:45Z  in response to SystemAdmin
    Hello James,

    Does it make sense for you to make the get call first? Then if the map supports null values and if you got back a null, to then call containsKey to distinquish the key with a null value versus a key which doesn't exist.

    Eric
    • SystemAdmin
      SystemAdmin
      1485 Posts
      ACCEPTED ANSWER

      Re: Loader behavior with containsKey

      ‏2012-09-13T13:57:21Z  in response to SystemAdmin
      Thanks for the response Eric.

      I believe this solves the issue I was having, but it creates another issue when the key doesn't actually exist. There will be a cache miss, and the loader will call the data store to get the value. The key will not exist in the data store, so the get will return null. Next, the contains key will be called and the key still will not exist in the cache and the loader will be called again.
      • SystemAdmin
        SystemAdmin
        1485 Posts
        ACCEPTED ANSWER

        Re: Loader behavior with containsKey

        ‏2012-09-14T17:11:07Z  in response to SystemAdmin
        Hello James,

        We should not go to the loader in the containsKey() when the get() did not find an entry so that is a non-issue.

        Eric
        • SystemAdmin
          SystemAdmin
          1485 Posts
          ACCEPTED ANSWER

          Re: Loader behavior with containsKey

          ‏2012-09-14T17:32:27Z  in response to SystemAdmin
          Are you saying that internally, XS will not make a call to the loader on a containsKey if the get operation did not return anything?

          I did a test like this, and I found that the loader was still called twice. However, let me double-check that behavior and make sure there is nothing wrong in my code somewhere.
          • SystemAdmin
            SystemAdmin
            1485 Posts
            ACCEPTED ANSWER

            Re: Loader behavior with containsKey

            ‏2012-09-14T19:26:45Z  in response to SystemAdmin
            Hello James,

            The behavior I described is if the calls are within a single transaction. It may be that you aren't using transactions.

            Pseudo-code:

            // key doesn't exist in map which supports null values
            session = grid.getSession()
            map = session.getMap(aMap)
            session.begin()
            key1 = someKey
            entry = map.get(key1) // returns null since no key in map - loader called
            map.containsKey(key1) // returns false - loader not called
            session.commit()

            Eric
            • SystemAdmin
              SystemAdmin
              1485 Posts
              ACCEPTED ANSWER

              Re: Loader behavior with containsKey

              ‏2012-09-14T19:58:21Z  in response to SystemAdmin
              Gotcha. Thanks a lot for the help Eric. I'm going to give this a shot.