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

Ask Your Question

Problem using local cache

We have an in-memory data grid that we are utilizing as datastore. It is read-only (for the moment) an populated using a custom cache loader (not as external data source due to internal problems with partitioning).

Our application works great in a non local cache mode but throw a RemoteDataAccessException when running in local cache mode. See error below.

What am I doing wrong? Stack trace is from a readMultiple operation in our code.

org.openspaces.core.RemoteDataAccessException: fail while caching; nested exception is: java.lang.IllegalArgumentException: Write operation requires object version greater than 0 when using local cache. Object=(class=com.hm.web.shop.site.domain.product.ModelInDepartment,uid=86027420^53^188314^0^0,version=0); nested exception is java.rmi.RemoteException: fail while caching; nested exception is: java.lang.IllegalArgumentException: Write operation requires object version greater than 0 when using local cache. Object=(class=com.hm.web.shop.site.domain.product.ModelInDepartment,uid=86027420^53^188314^0^0,version=0) at org.openspaces.core.exception.DefaultExceptionTranslator.internalTranslate(DefaultExceptionTranslator.java:96) at org.openspaces.core.exception.DefaultExceptionTranslator.translate(DefaultExceptionTranslator.java:46) at org.openspaces.core.DefaultGigaSpace.readMultiple(DefaultGigaSpace.java:260) at com.hm.web.shop.site.app.cache.gigaspaces.jpa.JpaQueryImpl.getResultList(JpaQueryImpl.java:48) at com.hm.web.shop.site.data.gigaspaces.GigaspacesModelInDepartmentQueryExecutor.getModelInDepartmentFromModelQuery(GigaspacesModelInDepartmentQueryExecutor.java:41) at com.hm.web.shop.site.data.ModelInDepartmentQueryExecutorTest.testGetModelInDepartmentFromModelQuery(ModelInDepartmentQueryExecutorTest.java:31) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)

Regards, Jakob Ericsson

{quote}This thread was imported from the previous forum. For your reference, the original is [available here|http://forum.openspaces.org/thread.jspa?threadID=2578]{quote}

asked 2008-09-08 10:29:39 -0500

jakeri gravatar image

updated 2013-08-08 09:52:00 -0500

jaissefsfex gravatar image
edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

You should have a @SpaceVersion field (this field should be int data type) as part of the POJO that will store the object version and have its value as 1 when loading its from the database. The space will increment this field value with every update to be used as part of the optimistic locking mechanism used when using local cache.


answered 2008-09-08 10:59:57 -0500

shay hassidim gravatar image
edit flag offensive delete link more


So even if I work in a read-only mode I have to implement optimistic locking?

There is no feature in GigaSpaces to handle this transparent?

jakeri gravatar imagejakeri ( 2008-09-09 02:01:04 -0500 )edit

Local cache running in optimistic locking by default. Have you managed to resolve this issue by having 1 as the initial value for the versionId field? Shay

shay hassidim gravatar imageshay hassidim ( 2008-09-09 07:10:00 -0500 )edit

We are trying to reproduce your problem.
Can you post your POJO and pu.xml?

shay hassidim gravatar imageshay hassidim ( 2008-09-09 08:29:14 -0500 )edit

I got it working when I added @SpaceVersion to our domain classes. Our code does not crash anymore.

As I said before, I am not using a PU for populating the space. I am running against a standard partitioned space (Data Grid) with two instances and one instance per VM (we will of course have backups in a production environment). This is populated using a writeMultiple script that read from our main datasource. I started using the provided external datasource to populate the space from Hibernate. This worked great until I got out-of-memory (-Xmx8g) on some of our largest tables (about 2.7 million rows). I wrote a PartitionedDefaultHibernateExternalDataSource.intialLoad to read the data in partitioned way but the largest table does not have a @SpaceRouting (partitioned on the primary key). We are aware that this is not an optimal solution but we have a legacy database that we have to work with for the moment.

And as I understand GigaSpaces will discard unwanted entries for a specific partition after it has added all the values to the partition. Am I right here? How does the consumer of the DataIterator returned from initialLoad discard objects that do not belong to its partition? Before or after it has been written to the space? My tests looks like it will write all objects to the space (even objects that do not belong to this partition) and then after, discard unwanted objects for this partition.


jakeri gravatar imagejakeri ( 2008-09-09 09:51:31 -0500 )edit


The EDS.initialLoad low level functionality filters out the data read from the database before it is written to the collocated space. It filters out the objects based on the routing field value – the ones that do not belong to the space are not written.

Using writeMultiple to load the data is a valid option only if you have the External Data source running in read-only mode (not writing data to the database) or when you are not using the Mirror. This will make sure data will not be written back to the database.

Any chance you got out of memory with your PartitionedDefaultHibernateExternalDataSource since you loaded all the data from the database into the memory and not used scrollable iterator that read the data in chunks?


shay hassidim gravatar imageshay hassidim ( 2008-09-09 16:30:11 -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: 2008-09-08 10:29:39 -0500

Seen: 56 times

Last updated: Sep 08 '08