[infinispan-dev] RemoteCache vs BasicCache

[Sanne Grinovero]

On 9 July 2013 18:01, Mircea Markus <mmarkus at redhat.com> wrote:
>
> On 9 Jul 2013, at 13:47, Sanne Grinovero <sanne at infinispan.org> wrote:
>
>> Indeed that's an excellent idea. But I would add also a common parent
>> interface having the basic functionality common to all.
>
> If ConcurrentMap doesn't have what we need, of course :-)

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()

-- Sanne




>
>>
>> On 9 July 2013 11:39, Mircea Markus <mmarkus at redhat.com> wrote:
>>>
>>> On 9 Jul 2013, at 13:15, Sanne Grinovero <sanne at infinispan.org> wrote:
>>>
>>>> On 8 July 2013 20:37, Mircea Markus <mmarkus at redhat.com> wrote:
>>>>> TBH I think having the RemoteCache implementing Cache wasn't such a good idea as it caused confusion through users: e.g. people trying to use transactions with a remote cache. I like the multiple interfaces idea as it clearly indicates what's actually supported in both remote and embedded modes.
>>>>
>>>> Right that has been confusing, but now we also have evidence of people
>>>> specifically demanding to have the same query functionality (same =
>>>> exact same API) in remote as in embedded.
>>>>
>>>> Yes we have different functionality, but also there is a good value in
>>>> being able to easily switch a client from embedded vs remote .. what
>>>> about we maintain two different interfaces but having a shared parent?
>>>>
>>>> We would then try to define as much as possible in the common Cache
>>>> interface, and regularly promote features from the lower interfaces to
>>>> the upper ones when the functionality is covered by both.
>>>>
>>>> In terms of practical development it's self-evident that we'll always
>>>> be a step ahead in embedded mode, so we should design for it rather
>>>> than trying to prevent it.
>>>
>>> That would work but I think it would be nicer to have separate interfaces to define the functionality, as suggested by Tristan:
>>>
>>> 3. we go even further and split the concept of BasicCache into multiple
>>> interfaces: AsyncCache, TransactionalCache, QueryableCache, etc and add
>>> them to the RemoteCache as we will in the blanks, since we are aiming at
>>> feature parity. This could also mix well with the ideal of having the
>>> JCache API as our public API.
>>>
>>> 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
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> 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