CopyMode attribute
You can tune the number of copies by defining the CopyMode attribute of the BackingMap or ObjectMap objects in the ObjectGrid descriptor XML file.
For Java™ applications, you can tune the number of copies by defining the CopyMode attribute of the BackingMap or ObjectMap objects.
For .NET applications, only COPY_TO_BYTES mode is supported.
- COPY_ON_READ_AND_COMMIT
- COPY_ON_READ
- NO_COPY
- COPY_ON_WRITE
- COPY_TO_BYTES
- COPY_TO_BYTES_RAW
Be careful when you use the NO_COPY attribute value with maps that can be updated. WebSphere® eXtreme Scale uses the copy on first touch to allow the transaction rollback. The application only changed the copy, and as a result, eXtreme Scale discards the copy. If the NO_COPY attribute value is used, and the application modifies the committed value, completing a rollback is not possible. Modifying the committed value leads to problems with indexes, replication, and so on because the indexes and replicas update when the transaction commits. If you modify committed data and then roll back the transaction, which does not actually roll back at all, then the indexes are not updated and replication does not take place. Other threads can see the uncommitted changes immediately, even if they have locks. Use the NO_COPY attribute value for read-only maps or for applications that complete the appropriate copy before modifying the value. If you use the NO_COPY attribute value and call IBM® support with a data integrity problem, you are asked to reproduce the problem with the copy mode set to COPY_ON_READ_AND_COMMIT.
The COPY_TO_BYTES value stores values in the map in a serialized form. At read time, eXtreme Scale inflates the value from a serialized form and at commit time it stores the value to a serialized form. With this method, a copy occurs at both read and commit time.
When you use optimistic locking with COPY_TO_BYTES, you might experience ClassNotFoundException exceptions during common operations, such as invalidating cache entries. These exceptions occur because the optimistic locking mechanism must call the equals() method of the cache object to detect any changes before the transaction is committed. To call the equals() method, the eXtreme Scale server must be able to deserialize the cached object, which means that eXtreme Scale must load the object class.
To resolve these exceptions, you can package the cached object classes so that the eXtreme Scale server can load the classes in stand-alone environments. Therefore, you must put the classes in the class path.
If your environment includes the OSGi framework, then package the classes into a fragment of the objectgrid.jar bundle. If you are running eXtreme Scale servers in the Liberty, package the classes as an OSGi bundle, and export the Java packages for those classes. Then, install the bundle by copying it into the grids directory along with your objectgrid.xml file.
In WebSphere Application Server, package the classes in the application or in a shared library that the application can access.
Alternatively, you can use custom serializers that can compare the byte arrays that are stored in eXtreme Scale to detect any changes.
The default copy mode for a map can be configured on the BackingMap object. You can also change the copy mode on maps before you start a transaction by using the ObjectMap.setCopyMode method.
<cc:backingMap name="RuntimeLifespan" copyMode="NO_COPY"/>