Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question

LRU read by ID memory_only_search behavior?


I have a setup a persistent space using mirror and with LRU cache policy. I have written some objects into the space and evicted them all using gigaspace.clear(EVICT_ONLY), and confirmed they are still in the DB. When I perform a gigaspace.count(), it returns 0 as expected. But when I perform a gigaspace.readById(clazz, id, ReadModifiers.MEMORY_ONLY_SEARCH), it returns the object. I expected it to return null because they were evicted. After the read by ID operation is performed, gigaspace.count() now returns 1. So the object was loaded back into the space.

Is this the expected behavior? I'm using GigaSpaces XAP Premium 10.2.0 GA build 13819

asked 2017-11-21 14:07:31 -0500

dncheu1 gravatar image

updated 2017-11-21 14:31:05 -0500

edit retag flag offensive close merge delete

3 Answers

Sort by ยป oldest newest most voted

Issue was resolved with support team. I was calling readById(Class claszz, String uuid, ReadModifiers.MEMORY_ONLY) which ended up invoking API readById(Class clazz, Object uuid, Object routing) and the ReadModifiers was "interpreted" as the routing parameter, with default ReadModifier. I switched to readById(IdQuery<t>(Class clazz, Object id), Long timeout, ReadModifiers MEMORY_ONLY) and it worked.

answered 2017-12-05 13:19:49 -0500

dncheu1 gravatar image
edit flag offensive delete link more


Your understanding is correct and the readById with MEMORY_ONLY_SEARCH shouldn't return the object if the object is not in space.

Is there any chance you written back this object before reading it again?

Can you please open a case through our support portal and we will report this issue to rnd and provide you a fix?

Here is the link to sign in to the support portal: https://support.gigaspaces.com/VF_Com...

Reagrds, Inbar

answered 2017-11-23 03:16:30 -0500

inbarc gravatar image
edit flag offensive delete link more


No, the object wasn't written back. The sequence of my test was to write object to the space, call evict and check the GS UI that the space has no objects. Then readById with memory_only and expect it to return null. Instead an object was returned and the UI showed there was now 1 object in the space. Thanks, I will raise a support ticket.

dncheu1 gravatar imagedncheu1 ( 2017-11-28 09:11:27 -0500 )edit

According to the documentation, the Take and Clear Modifiers EVICT_ONLY, work to remove from the memory only and not the persistent store. See: https://docs.gigaspaces.com/xap/10.2/...

Also from the same web page, "In a persistent space mode, evicting a space object means that a space object is simply be removed from the space memory, but is still be available through the underlying RDBMS. The space reloads this object back into the space memory only if it was requested by a specific read operation."

answered 2017-11-21 14:47:50 -0500

Dixson Huie gravatar image
edit flag offensive delete link more


My question was specifically about the readById with MEMORY_ONLY_SEARCH modifier. I did not expect it to return the object because it was evicted from space, and the modifier says to search only memory. Is my understanding incorrect?

dncheu1 gravatar imagedncheu1 ( 2017-11-21 15:02:47 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2017-11-21 14:07:31 -0500

Seen: 129 times

Last updated: Dec 05 '17