POF type-id validation on Put()

Question

From an extend client I am able to create an object that implements IPortableObject in .NET. I can define it in the Extend Client's POF file allowing me to put it in a distributed cache.
However, the object is not defined nor even exists in the cluster. The put works fine (since its storing the serialized version) and the only problems arise when I perform an operation that requires object deserialization inside the cluster.
An example would be passing back an EqualsFilter on a specific property. As you know, if the property is non-indexed, the cache must deserialize all of the objects to perform the comparison. Since the rogue object is not deserializable on the cluster an exception is thrown
Caused by: Portable(java.lang.IllegalArgumentException): unknown user type: 6000
Once this exception is thrown, the operation exits and my query with the filter is rendered useless.
Is there a way to force coherence to validate the type id of the pof stream when an object goes into the cache initially, disallowing the put in the first place?
Someone experimenting in our dev environment rendered the client application useless by inserting two rogue objects like this without realizing what they were doing. The specific cache was basically down until I removed these two objects.
Thanks!

Answer 1

Hi Jarrod,
You can force deserialization on put by configuring a dummy cache store for your cache, or by creating and configuring a backing map listener that attempts to deserialize the object. That way you will fail early, but because both of these approaches introduce additional overhead, you will probably want to disable them in production (I'd probably use BML which can be configured via system property to either validate the object or not. That way you can simply disable the validation in production, without having to maintain multiple cache config files).
However, if you are using Coherence 3.5, you have some other options:
1. You can create a backing map listener that uses PofValue to extract POF type id from your serialized object, and check if the type is registered with the PofContext. The problem with this approach is that you will only be able to validate that the top-level type is registered. You might still run into issues if the type of one of the nested objects is not registered.
2. You can use PofExtractor instead of default ReflectionExtractor for your queries, index creation, etc. This will actually eliminate the need for the Java class completely, so it might save you a significant amount of work (if you don't need Java class for other reasons, that is).
Regards,
Aleks