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

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

    Re: Loader behavior with containsKey

    ‏2012-09-11T13:02:17Z  
    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

    Re: Loader behavior with containsKey

    ‏2012-09-13T13:39:45Z  
    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

    Re: Loader behavior with containsKey

    ‏2012-09-13T13:57:21Z  
    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
    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

    Re: Loader behavior with containsKey

    ‏2012-09-14T17:11:07Z  
    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.
    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

    Re: Loader behavior with containsKey

    ‏2012-09-14T17:32:27Z  
    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
    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

    Re: Loader behavior with containsKey

    ‏2012-09-14T19:26:45Z  
    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.
    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

    Re: Loader behavior with containsKey

    ‏2012-09-14T19:58:21Z  
    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
    Gotcha. Thanks a lot for the help Eric. I'm going to give this a shot.