Efficient way to move an object between two distributed or near caches without re-serialization?

[javafanboy]

I am looking at a use-case where we may want to move old versions of objects indexed by key to a "history cache" (indexed by the same key with an appended version id) where they would sit for a specified time. As objects in our case can be quite large and require non-trivial CPU cycles to re-serialize (and for that matter transfer over the network) I am asking for advice if there are any clever methods that could be used to take the serialized form of the object in one cache and store it directly in another cache?

Assuming the above is possible and placement for the two caches was arranged in a way that the object always would be placed in the same node in both caches are there any way to using coherence features like update processors extract the above discussed serialized form from one cache (preferably as part of the process to replace it with a new version) and directly insert it into the corresponding partition in the history cache without passing the network stack (ideally even having to "copy" the data) or are coherence using some type of isolation mechanism (like class loaders) between caches that makes this impossible?

[aseovic]

Yes, with some caveats ;-)

1. You would need to use low-level backing map APIs within an entry processor to get the associated entry from your history cache. It will be created if it doesn't exist, and enlisted into the current partition-level transaction.

2. In order for the data affinity/key association to work, the history cache would have to be on the same service that your main cache is on, so it cannot be configured differently (at least with regard to service-level parameters, such as threads, partition counts, etc. It can have different cache-level parameters, such as expiry, high units, etc.)

3. You would need a composite key containing both the original key and the version, with key association set up on the original key. You could write your own, or you could use a built-in CompositeKey class for this.

Basically, assuming you have history cache on the same service as cache, something along these lines should do the job:

        NamedCache<String, Value> cache = CacheFactory.getCache("cache");
        cache.invoke("myKey", (entry) ->
            {
            BinaryEntry<String, Value> binEntry = entry.asBinaryEntry();

            Integer version = 1;   // not sure how you decide what the version should be...
            BinaryEntry<CompositeKey<String, Integer>, Value> historyEntry =
                    binEntry.getAssociatedEntry("history", new CompositeKey<>(entry.getKey(), version));

            // pass true as a second argument if you want the update/removal to be synthetic
            historyEntry.updateBinaryValue(binEntry.getBinaryValue(), false);  
            binEntry.remove(false);
            return null;
            });

Obviously, you could package the code above into a CopyProcessor class, parametrize it the way you need to provide history cache name, version and whether the update/removal should be synthetic or not, etc. And the key and value type can be anything you need -- I just used String for the key and Value for the value type for illustration purposes.

HTH.

[javafanboy]

Happy to see this is possible and thanks for the code example!