How about adding setTypeNames() configuration property that will be similar
to setTypes(), but for binary objects?
-Val
On Tue, Mar 29, 2016 at 1:56 AM, Denis Magda <dma...@gridgain.com> wrote:
> Igniters,
>
> In some cases there is necessity to control a type of object that is being
> inserted into a cache.
> Presently this kind of check is accomplished at compile time only relying
> on Java Generics. However it doesn't prevent us from connecting to a
> cluster using a non-generic instance of a cache and put any kind of data in
> it.
> This may be not a harmful intention but rather a silly developer mistake.
>
> I see the following options here.
>
> 1) First CacheInterceptor based approach.
> Specify a unique interceptor per cache setting expected typeName/typeId to
> it at construction time and the interceptor will validate object type in
> onBeforePut() method.
> Disadvantages:
> - cache interceptor have to be created for every cache;
> - cache interceptor class has to be located in servers classpath. It means
> that we won't be able to start a new cache with its interceptor later.
>
> 2) Second CacheInterceptor based approach.
> A generic cache interceptor can be created. It will be populated with a
> map of cacheName->typeName values at initialization time and validation may
> look like below
>
> @CacheNameResource String cacheName;
>
> public Object onBeforePut(Cache.Entry<String,BinaryObject>
> entry,BinaryObject newVal) {
> if (typeId ==null) {
> synchronized (cachesTypes) {
> if (typeId ==null) {
> String allowedType =cachesTypes.get(cacheName);
>
> if (allowedType ==null) {
> typeId =0;
>
> throw new IgniteException("No type for cache name:"
> +cacheName);
> }
>
> typeId = Ignition.ignite().binary().typeId(allowedType);
> }
> }
> }
>
> if (newVal.type().typeId() !=typeId)
> throw new IgniteException("Invalid object type [validType="
> +typeId +", wrongType=" + newVal.type().typeId());
>
> return newVal;
> }
>
> However if we want to start a new cache then we won't be able to add a new
> entry to "cacheTypes" map. 3) MutableConfiguration.setTypes(Class<K>
> keyType, Class<V> valueType) based approach According to the spec
>
> Implementations may further perform type checking on mutative cache
> operations * and throw a {@link ClassCastException} if these checks fail.
>
> If we see that value type is BinaryObject (this can be a case if there
> BinaryObject is not going to be deserialized because no real class exists
> for it) then we can take its typeName/typeId and compare it with the same
> parameters at the time instances of BinaryObjects will be put to cache
> using cache.put(). So, every time cache.put()/putAll() are called we can
> check type on client nodes before sending values to servers. In case of
> CacheEntryProcessors servers will double-check an entry type after the
> entry processor does its job. I prefer the latest approach. Any thoughts on
> this? -- Denis
>
