[infinispan-dev] RemoteCache vs BasicCache

Sanne Grinovero sanne at infinispan.org
Wed Jul 10 06:37:19 EDT 2013


On 10 July 2013 11:32, Mircea Markus <mmarkus at redhat.com> wrote:
>
> 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.

Fair enough. I just assumed you where discussing about breaking the
backwards compatibility, if not that's very welcome.

>
>> 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.

That sounds like it still breaks backwards compatibility.. possibly I
have not understood how you envision that.

Cheers,
Sanne

>
>>
>> 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)
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



More information about the infinispan-dev mailing list