Transactions documentation and a difficult(?) use-case...

Question

I would like detailed information about how TransactionMap work with different isolation levels, ie how both changes performed by the application holding the map and in the distributed cache is propagated between them etc.
More detailed information about the TransactionMap.Validator would also be very appreciated.
We also have one specific "use case" I would like advice about - it goes like this:
We use one type of main object that has a very tight coupling to a varying number (0 to a few hundred in the extreme case) small detail objects. All the detail objects are always required as soon as the main object is used. A given detail object is never referenced from more than one main object. We have (for performance reasons) decided to treat the detail objects as "part of" the main object. The main objects are stored in the cache.
Users can make changes to the main objects themselves or to there detail objects. A user should be able to perform many changes to many main objects (and there detail objects) and "commit" them all at once pressing a button.
Now to the problem:
We would like to allow users to make "non conflicting" changes to a main objects detail objects - ie if two users has changed different detail objects we want to merge the changes instead of refusing the modification at commit. To be able to do this we intend to keep version numbers not only on the main object but also on the detail objects.
We would like to use "transactions" to handle the requirement that all a users changes should be "committed" at once and either all be introduced or not introduced at all (in the event of hardware failure during update for instance!) but the default behavior of Transaction is as I understand it (I have so far just read about it not played around with it much!) to compare the "whole object" for equality in the prepare (and commit?) steps. We also need exact information about WHAT object(s) that had been concurrently modified in the case a commit cant be performed allowing the user to "refresh" the relevant detail object only and retry committing his changes.
How would we be able to implement our "use case" in a good and reasonably efficient way given Coherents features? Would it for instance be possible (with a reasonable effort) to create our own transaction validation that could perform "merging of "non-conflicting" changes to the same object and in that case how should we go about it?
Best Regards
Magnus

Answer 1

Hi Magnus,
Our entry processor functionality is your best solution, but unfortunately is not fully supported within a transactional context.
I would suggest using a combination of explicit locking (as opposed to implicit transactions) and our entry processor functionality (new in 3.1).
Using explicit locking, you can enforce atomic access to cache entries. Using the entry processor you can perform partial updates locally on the server (allowing you to send only changes).
So the sequence would be:
* lock all "main objects"
* if necessary, validate the main objects (see below)
* use entry processors to perform "delta updates" against those main objects
* unlock the main objects
The locking is only required for atomicity (ensuring that updates don't overlap), and does require that all modifiers follow the same locking pattern. You may either design your objects so that you know the delta updates will complete successfully, or you'll need to verify the updates will succeed prior to actually executing the updates.
Jon Purdy
Tangosol, Inc.