[infinispan-dev] Dropping AtomicMap/FineGrainedAtomicMap

[Mircea Markus]

Dropping the FGAM API is just an idea and there were valid concerns for not doing it immediately. Indeed the reason it was considered for removal is in order not to  keep around two APIs that do the same thing. That is if really do the same thing. As a first step would be good to enhance the grouping API[1] to support group handling methods. Then see if grouping works for the (FG)AM users: if it does, we can drop FGAM. If it doesn't we'll fix FGAM. 

[1] https://issues.jboss.org/browse/ISPN-3981


On Feb 10, 2014, at 9:57 AM, Sanne Grinovero <sanne at infinispan.org> wrote:

> On 10 February 2014 09:02, Galder Zamarreño <galder at redhat.com> wrote:
>> 
>> On 27 Jan 2014, at 11:27, Dan Berindei <dan.berindei at gmail.com> wrote:
>> 
>>> I think it's way too early to discuss removing FineGrainedAtomicMap and AtomicMap, as long as we don't have a concrete alternative with similar properties.
>> 
>> You have a point there, but we can’t ignore the feedback that says that atomic maps are not being used because they are buggy, and instead they are using grouping.
> 
> Let's not generalize too much, some are still doing the opposite and
> have commented on their good reasons ;-)
> 
>> 
>> Deeply, I think we have two ways of doing the same thing, which is confusing from my POV, and one of them is not being used enough, or we’re not fixing the stuff there.
> 
> +1 but since as you say there is confusion, I'm not sure if they
> really are the same thing. I've asked for a detailed comparison but
> the discussion derailed. It would probably help a lot if someone from
> the Infinispan core team would reimplement the FGAM API on top of
> Grouping, making sure to guarantee the same semantics also in terms of
> concurrency, isolation and acidity.
> That would provide the implementation cleanup you'd all love, a
> migration path, and probably some deeper considerations on their
> differences; I also suspect there would be some roadblocks,
> potentially subtle differences which could then be better documented?
> 
>> 
>> Regardless of whether it’s too early or not, this email is trying to spark a consolidation of the two technologies into a single solution that works for everyone and we maintained it actively :)
>> 
>>> Cache.getGroup(groupName) is just a method name at this point, we don't have any idea how it will compare to AtomicMap/FineGrainedAtomicMap from a transaction isolation or performance perspective. BTW, do we really need the group name to be a String?
>>> 
>>> A good way to prove that the grouping API is a proper replacement for the atomic maps would be to replace the usage of atomic maps in the Tree module with the grouping API. Unless we plan to drop the Tree module completely…
>> 
>> Tree was only ever meant as a bridge for JBC users to move to Infinispan. Paul F et al tried to build HTTP sessions on top of that, it didn’t work. Then they tried to do it on top of Atomic Maps, and it didn’t work either, and finally they’re using grouping and seems to work?
> 
> I don't think that proves that Atomic Maps where not working, if any
> it's a statement that grouping is a better fit for this specific use
> case?
> BTW having a use case which matches way better that the other just
> highlights that this is no duplicate functionality, but rather quite
> different stuff.
> 
> From an Hibernate OGM perspective it would be great to have some more
> stability in not so old APIs, at least until there's a clearly
> documented migration to grouping.
> 
> Sanne
> 
>> 
>> Cheers,
>> 
>>> 
>>> Cheers
>>> Dan
>>> 
>>> 
>>> 
>>> On Wed, Jan 22, 2014 at 2:45 PM, Mircea Markus <mmarkus at redhat.com> wrote:
>>> 
>>> On Jan 21, 2014, at 8:42 PM, Vladimir Blagojevic <vblagoje at redhat.com> wrote:
>>> 
>>>> I agree with Erik here. Deltas are used in M/R and I've never detected
>>>> any problems so far.
>>>> On 1/21/2014, 1:39 PM, Erik Salter wrote:
>>>>> Please don't remove the Delta stuff.  That's quite useful, especially for
>>>>> large collections.
>>> 
>>> +1 to keep DeltaAware. Thanks for the feedbak
>>> 
>>>>> 
>>>>> Erik
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> 
>> --
>> Galder Zamarreño
>> galder at redhat.com
>> twitter.com/galderz
>> 
>> Project Lead, Escalante
>> http://escalante.io
>> 
>> Engineer, Infinispan
>> http://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)