Best way to keep a 'history' of cache changes?

Question

Simple question, really, which I guess many people have run into before, so I'm looking for a bit of 'best practice' as regards Coherence.
We have a distributed cache which is holding financial data (Portfolio Positions), and we plan to update these using Entry Processors for scalability (as a single incoming Trade could affect multiple Positions, so we want them processed in parallel). So far, so good. (I hope! If you have a better approach, please feel free to add it. :))
Now, each Position that is modified needs to be 'audited', so we have a 'before' and 'after' image. This needs to be persisted. I have currently created a separate cache - 'PositionHistoryCache' - and set it up so it's flushed to Oracle in a "write behind" manner. This seems to work OK - i.e. updating this 'other' distributed cache from within the Entry Processor works fine. Does this seem sensible as an approach as regards keeping 'history' - i.e. using a separate cache and 'put'ing to it?
Also, I'm keen not to run into any 'reentrancy' problems in our application. So what's the general rule here, when we are using Entry Processors elsewhere? Is it simply the 'service name' that determines whether the distributed caches are served by different service threads? In other words, as long as the 'history' cache we are trying to talk to is declared with a different 'service-name' to the cache that has the calling Entry Processor we can freely 'put' to it without issue?
Many thanks if you can help clear up the above design issues.

Answer 1

Hi Steve,
yes, the (possibly inherited) service name for the cache scheme determines which cache service a cache belongs to.
As for best practice, you probably would want to use key-affinity and the cache same service for the audit cache and try to put the data into the backing map directly. Since this is inserts and child records we are speaking about (access to the audit record is demarcated by access to the to-be-audited record, and if you do it from an entry-processor then the audit entry is always local because it is affine to the to-be-audited entry), it should be safe, provided that you only ever insert/update the audit entry into the backing map from entry processors manipulating the parent entry.
You would still have the same failure cases as the different cache service cache.put approach: if you crash after the audit record has been inserted but process did not finish, then you may end up with lost but audited updates or duplicate audit records for a single change.
Note that this is an advanced functionality and you would probably want to consult with your Oracle support representative to ensure that you know the implications this approach brings with itself with each Coherence version you try to use it with.
An alternative approach would be to move audit into the same cache as the record and use key affinity to ensure audit records reside on the same node as the audited record, and use EntryProcessors sent to both the changed and the audit entry keys together to update both records together atomically. This is a much safer approach, it is guaranteed to be atomic as long as only the cache is concerned, on the other hand you need to know the audit entry key in advance and use the key-based invokeAll method (you can't use the filter-based invokeAll method as that cannot add new entries). Also you have additional work if you use filter-based read operations to filter out audit records from query results.
Best regards,
Robert