[infinispan-dev] RemoteCache vs BasicCache

Mircea Markus mmarkus at redhat.com
Wed Jul 10 06:32:16 EDT 2013


On 9 Jul 2013, at 20:22, Sanne Grinovero <sanne at infinispan.org> wrote:

>>> ConcurrentMap adds a load of pitfalls which should not be there: all
>>> the methods whose result is depending on the node they are run on.
>>> 
>>> I know we make it clear in javadocs and several warnings on the doc,
>>> but experience tells that this is not good enough :-(
>>> 
>>> I'd propose to remove them all, and provide an adapter layer
>>> (optional) for those needing to replace a ConcurrentMap in their code.
>>> Methods like "size()" - as discussed before - are possibly useful for
>>> statistics and diagnostics, and therefore should be accessed in a
>>> different explicit way.
>>> 
>>> cache.diagnosticsStatistics().localContainerSize()
>> 
>> +1. That would be part of the migration towards to JCache API and implemented in 7.0. I think Tristan was looking for something now.
> 
> I see. But since we plan a change anyway, why not doing the right
> thing right away?

That would making Cache not implement the j.u.ConcurrentMap interface but a new interface, potentially the one exposed by JSR 107. Whilst the timing is good (new major) I think that is a rather large change in the context of the already very busy 6.0 and not as important as other features or stability. There's also JDG backward compatibility. I guess Tristan can comment more on the effort needed for implementing such a change.

> Ok we can change interfaces on mayor versions, still
> the less you change them the better: any change is a big pain for
> other projects.

This is not that much a change in method signature but only moving methods around to separate interfaces.

> 
> Unless Tristan was looking for something backwards compatible right
> now? Of course I'd prefer that, I was making suggestions assuming the
> interface chain would change now in some non-compabile way.

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)







More information about the infinispan-dev mailing list