WebSphere eXtreme Scale Best Practices for Operation and Management

Chapter 6. Performance planning for application developers 113

The application must destroy all map entry references after the transaction is committed. If

the application fails to destroy the entry references, the application might cause the data that

is cached in the BackingMap to become corrupted. If an application uses this mode and has

problems, switch to COPY_ON_READ_AND_COMMIT mode to see if the problem still exists. If the

problem no longer exists, the application is failing to destroy all of its references after the

transaction has committed. Note that if you have a distributed grid and if you have disabled

near cache, COPY_ON_READ_AND_COMMIT effectively behaves the same as COPY_ON_READ.

6.1.3 COPY_ON_WRITE mode

COPY_ON_WRITE mode improves performance over COPY_ON_READ_AND_COMMIT mode (for a local

container or near cache) by eliminating the copy that occurs when the ObjectMap.get method

is called for the first time by a transaction for a given key. The ObjectMap.get method returns

a proxy to the value instead of a direct reference to the value object. The proxy ensures that a

copy of the value is not made unless the application calls a set method on the value interface

that is specified by the valueInterfaceClass argument. For COPY_ON_WRITE to work, your value

object must implement a Java interface and your client code must refer only to the interface

type; WebSphere eXtreme Scale uses your interface for its proxy. The value objects must also

follow the JavaBeans pattern for setter methods.

The proxy provides a copy on write implementation. The application must still call

update(key,value) if it updates a value. However, when a transaction commits, the

BackingMap examines the proxy to determine whether a copy was made as a result of a set

method being called. If a copy was made, the reference to that copy is stored in the

BackingMap. The advantage of this mode is that a value is never copied on a read or at

commit if the transaction does not call a set method to change the value.

COPY_ON_WRITE also permits an application to examine a value prior to commit to see what

attributes were modified, if any. The proxy that the application holds implements not only your

own interface but also WebSphere eXtreme Scale’s ValueProxyInfo. A method of the latter

returns a list (by name) of the value’s attributes that were modified.

6.1.4 NO_COPY mode

NO_COPY mode allows an application to declare that it never modifies a value object that is

obtained using an ObjectMap.get method in exchange for performance improvements. If this

mode is used, no copy of the value is ever made. If the application modifies values, the data in

the BackingMap is corrupted.

NO_COPY mode is useful for read-only maps where data is never modified by the application.

This mode is not typically recommended to application developers, because it allows direct

access to editing the grid data, regardless of transactions and locks. It is only safe to use this

mode with read-only data, or where only one JVM at a time, and only one thread on that JVM

at a time, will change a given value. An example of this mode is HTTP session management.

6.1.5 COPY_TO_BYTES mode

You can store the key value pairs in a BackingMap in a byte array instead of plain old Java

object (POJO) form, which reduces the memory footprint that a large graph of objects can

consume. By reducing a complicated graph of objects to a byte array, only one object is

maintained in the heap instead of several objects. With this reduction of the number of objects

in the heap, the Java run time has fewer objects to search for during garbage collection.

When using byte arrays, note that having an optimized serialization mechanism is critical to

seeing a reduction of memory consumption. COPY_TO_BYTES can also save significant