Simple get vs entry processor for processsing 'get' requests

Question

We're wondering about the best way to handle a simple get where we want to do some processing on the request:
1. we might want to authenticate/authorize a proxy as well as an 'implied' user sitting behind the proxy
2. we might need to look up the cache entry by modifying the key presented by the user: for example, changing capitalization
3. we might even have multiple aliases for the cache entry but only store it once to avoid data duplication-- in this case, we'd need to resolve an alias to another name entierly.
Would it be best to use an entry processor to do this (a 'GetProcessor') or is there a better way using simple 'get' in the basic api with some server-side logic to intercept the request and do the processing? If the latter, can you please explain how to do it?
And please point out any performance considerations if you can.
Thanks!
Edited by: Murali on Apr 25, 2011 2:51 PM

Answer 1

Hi Murali,
You would probably be better off using an Invocable and InvocationService for what you want to do. The main reason for this would be points 2 and 3 where you say you might want to modify the key or have aliases (I presume you mean aliases for keys).
If you use a get or an EntryProcessor these two requests would be routed to the storage member that owns the key of the get request or EntryProcessor invoke. If you then wanted to modify the key the get or EntryProcessor may now be on the wrong node as a different node may own the new key.
If your data access requests are all coming from client applications over Extend and not from within cluster members then you could intercept calls to the cache on the Extend Proxy and do your extra processing and key modification there. There are a couple of different ways of doing this depending on what version of Coherence you are using and whether this is restricted to a few caches or all caches. Coherence 3.6 and above make this easier as they introduce methods and configuration as part of the security API that would allow you to intercept calls an easily wrapper caches. It is still possible in 3.5 but a bit more work.
Probably the easiest way on an ExtendProxy is to create a wrapper class that can wrap the real cache and intecept the required methods. You can do this by extending WrapperNamedCache and overriding the methods you want to intercept, such as get(). Actually making Coherence use your wrapper instead of the real cache can be done a number of ways depending again on which version of Coherence you have.
Are all your data access requirements just gets or do you intend to use Filter queries? Obviously any query made againsta a cache where the Filter was targeted at the Key rather than the value would fail if the filter was using unmodified key values. You would also need to cope with getAll requests.
If you can expand a bit on where the requests for data will come from (i.e. are they all form Extend clients) and which version of Coherence you have then it would be possible to give a better answer as right now there are quite a few possibilities.
JK