See the WebSphere eXtreme Scale Wiki for links to eXtreme Scale Version 7.0 documentation.
If you log in
with your developerWorks ID, you can leave comments and feedback for the development team.
ObjectGrid uses transactions for the following reasons:
- To protect a thread from concurrent changes
- To apply multiple changes as an atomic unit at commit time
- To implement a life cycle for locks on changes
- To act as the unit of replication
When a transaction starts, ObjectGrid allocates a special difference map to hold the current changes or copies of key and value pairs that the transaction uses. Normally, when a key and value pair is touched, then the value is copied before the application receives the value. The difference map tracks all changes as operations such as insert, update, get, remove, and so on occur. Keys are not copied because they are assumed to be immutable. If an ObjectTransformer is specified, then it is used for copying the value. If the transaction is using optimistic locking, then before images of the values are also tracked for comparison when the transaction commits.
If a transaction is rolled back, then the difference map information is discarded, and locks on entries are released. When a transaction commits, then the changes are applied to the Maps and locks are released. If optimistic locking is being used, then ObjectGrid compares the before image versions of the values with the values that are in the Map. These values must match for the transaction to commit. This comparison allows a multi-version locking scheme, but at a cost of two copies being made when the entry is touched by the transaction. All values are copied again and the new copy is stored in the Map. ObjectGrid performs this copy to protect itself against the application changing the application reference to the value after a commit.
You can avoid using several copies of the information. The application can save a copy by using pessimistic locking instead of optimistic locking as the cost of limiting concurrency. The copy of the value at commit time can also be avoided if the application agrees not to change a value after a commit.
CopyMode attribute
You can tune the number of copies by defining the CopyMode attribute of the BackingMap or ObjectMap. The copy mode has the following values:
- COPY_ON_READ_AND_COMMIT
- COPY_ON_READ
- NO_COPY
The COPY_ON_READ_AND_COMMIT value is the default. The COPY_ON_READ value copies on the initial touch, but does not copy at commit time. This mode is safe if the application agrees not to modify a value after committing a transaction. The NO_COPY value does not copy data, which is only safe for read-only data. If it never changes then there is no need to copy it for isolation reasons.
Be careful when using the NO_COPY attribute value with Maps that can be updated. ObjectGrid uses the copy on first touch to allow transaction rollback. The application only changed the copy, so ObjectGrid discards the copy. If the NO_COPY attribute value is used, then the application modifies the committed value, and rollback is impossible. 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 rollback at all in this case, then the indexes are not updated and replication does not take place. Other threads can see uncommitted changes immediately, even if they have locks. Use the NO_COPY attribute value only for read-only Maps or if you are willing to experience problems. If you use the NO_COPY attribute value and call IBM support, you are asked to set the copy mode to READ_AND_COMMIT.
The default copy mode for a Map can be configured on the BackingMap. You can also change the copy mode on a changed transaction by using the ObjectMap#setCopyMode method on the transaction.
Here is an example backing Map snippet from an objectgrid.xml fie showing how to set the copy mode for a given backing map, this assumes you're using cc as the objectgrid/config namespace:
<cc:backingMap name="RuntimeLifespan" copyMode="NO_COPY"/>
Automatic commit mode
If no transaction is actively started, then when an application interacts with an ObjectMap, an automatic begin and commit is done on behalf of the application. This automatic begin and commit works, but prevents rollback and locking from working effectively. Synchronous replication speed is impacted because of the very small transaction size. If you are using an EntityManager application, then do not use automatic commit mode because objects that are looked up with the EntityManager.find method immediately become unmanaged on the method return and become unusable.
Locking mode
You can specify the following locking settings:
- NONE
- Pessimistic
- Optimistic
The NONE setting is the fastest, but does not perform any locking. If you are using read-only data, then you might not need locking.
The Pessimistic setting acquires locks on entries, then and holds the locks until commit time. This locking strategy provides good consistency at the expense of throughput.
The Optimistic setting takes a before image of every record that the transaction touches and compares the image to the current entry values when the transaction commits. If the entry values change, then the transaction rolls back. No locks are held until commit time. This locking strategy provides better concurrency than the pessimistic strategy, at the risk of the transaction rolling back and the memory cost of making the extra copy of the entry.
Set the locking strategy on the BackingMap. You cannot change the locking strategy for each transaction.
Here is an example xml snippet showing how to set the locking mode on a map using the xml file, again this assumes cc is the namespace for the objectgrid/config namespace:
<cc:backingMap name="RuntimeLifespan" lockStrategy="NONE" />
External transaction coordinators
Usually, ObjectGrid transactions begin with the session.begin method and end with the session.commit method. However, when ObjectGrid is embedded, then the transactions might be started and ended by an external transaction coordinator. In this case, you do not need to call the session.begin method and end with the session.commit method. Refer to ObjectGrid and external transaction interaction how to coordinate with external transaction coordinator.
ObjectGrid ships with a built-in plugin for WebSphere Application Server. See the WebSphereTransactionCallback plug-in topic for details.
Related information
© Copyright IBM Corporation 2007,2009. All Rights Reserved.
