This topic has been locked.
7 replies Latest Post - 2012-09-14T19:58:21Z by SystemAdmin
Pinned topic Loader behavior with containsKey
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
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 06000288G652 PostsACCEPTED ANSWER
Re: Loader behavior with containsKey2012-09-11T13:02:17Z in response to SystemAdminStill 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.
Re: Loader behavior with containsKey2012-09-13T13:39:45Z in response to SystemAdminHello 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.
Re: Loader behavior with containsKey2012-09-13T13:57:21Z in response to SystemAdminThanks 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.
Re: Loader behavior with containsKey2012-09-14T17:32:27Z in response to SystemAdminAre 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.
Re: Loader behavior with containsKey2012-09-14T19:26:45Z in response to SystemAdminHello James,
The behavior I described is if the calls are within a single transaction. It may be that you aren't using transactions.
// key doesn't exist in map which supports null values
session = grid.getSession()
map = session.getMap(aMap)
key1 = someKey
entry = map.get(key1) // returns null since no key in map - loader called
map.containsKey(key1) // returns false - loader not called