Re: [infinispan-dev] Dropping AtomicMap/FineGrainedAtomicMap
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 wrote: > On 10 February 2014 09:02, Galder Zamarreño wrote: >> >> On 27 Jan 2014, at 11:27, Dan Berindei 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 wrote: >>> >>> On Jan 21, 2014, at 8:42 PM, Vladimir Blagojevic >>> 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@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@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> ___ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> -- >> Galder Zamarreño >> gal...@redhat.com >> twitter.com/galderz >> >> Project Lead, Escalante >> http://escalante.io >> >> Engineer, Infinispan >> http://infinispan.org >> >> >> ___ >> infinispan-dev mailing list >> infinispan-dev@lists.
Re: [infinispan-dev] Dropping AtomicMap/FineGrainedAtomicMap
On 10 February 2014 09:02, Galder Zamarreño wrote: > > On 27 Jan 2014, at 11:27, Dan Berindei 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 wrote: >> >> On Jan 21, 2014, at 8:42 PM, Vladimir Blagojevic 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@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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> ___ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Galder Zamarreño > gal...@redhat.com > twitter.com/galderz > > Project Lead, Escalante > http://escalante.io > > Engineer, Infinispan > http://infinispan.org > > > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Dropping AtomicMap/FineGrainedAtomicMap
On 27 Jan 2014, at 11:27, Dan Berindei 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. 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. 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? Cheers, > > Cheers > Dan > > > > On Wed, Jan 22, 2014 at 2:45 PM, Mircea Markus wrote: > > On Jan 21, 2014, at 8:42 PM, Vladimir Blagojevic 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@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Dropping AtomicMap/FineGrainedAtomicMap
The delta’s will remain, but they’re each key/value pair. Example: say you want to store a dehydrated list of three elements (“one”, “two”, “three”) in Infinispan Before you’d do (approx): key=my-list value=AtomicMap(k=1,v=“one”, k=2,v=“two”, k3=“v3”) Internally, we’d track deltas and only send those changes. What I propose we do is: key=1 (group=“my-list") value=“one” key=2 (group=“my-list") value=“two” key=3 (group=“my-list") value=“three” The delta’s are still there. Each changed key is sent separately, when it changes. This is not the final product of course. As agreed with Pedro, we’d need a way to have a view map for all key/value pairs associated with a given group, i.e. cache.getGroups(“my-list”). I know Sanne et al also need a way to have coarse grained locking on the entire group sometimes, as well as fine grained locking, so we’d need to find a way to accomodate that. Cheers, On 21 Jan 2014, at 21:42, Vladimir Blagojevic 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. >> >> Erik >> > > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Dropping AtomicMap/FineGrainedAtomicMap
On 20 Jan 2014, at 12:32, Pedro Ruivo wrote: > Hi, > > On 01/20/2014 11:28 AM, Galder Zamarreño wrote: >> Hi all, >> >> Dropping AtomicMap and FineGrainedAtomicMap was discussed last week in the >> F2F meeting [1]. It's complex and buggy, and we'd recommend people to use >> the Grouping API instead [2]. Grouping API would allow data to reside >> together, while the standard map API would apply per-key locking. > > +1. are we going to dropping the Delta stuff? The delta would be the k/v pair. Say you are storing HTTP sessions. With AMs, the key would be the session ID and all its attributes would be stored in the atomic map. Once you remove that, each session’s attributes is a single k/v pair in the cache, so that’s your delta. >> >> We don't have a timeline for this yet, but we want to get as much feedback >> on the topic as possible so that we can evaluate the options. > > before starting with it, I would recommend to add the following method > to cache API: > > /** > * returns all the keys and values associated with the group name. The > Map is immutable (i.e. read-only) > **/ > Map getGroup(String groupName); Yes, I think we’d need this for grouping to be able have a full replacement for atomic maps. You need a way to retrieve all the data associated with that group without the to iterate the cache yourself, or the need to add indexing. In the case of HTTP sessions, you’d give the session ID as key and it’d give you a map view of all the attributes associated with that session. Cheers, > > Cheers, > Pedro > >> >> Cheers, >> >> [1] https://issues.jboss.org/browse/ISPN-3901 >> [2] >> http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_the_grouping_api >> -- >> Galder Zamarreño >> gal...@redhat.com >> twitter.com/galderz >> >> Project Lead, Escalante >> http://escalante.io >> >> Engineer, Infinispan >> http://infinispan.org >> >> >> ___ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Dropping AtomicMap/FineGrainedAtomicMap
On Mon 2014-01-27 12:27, Dan Berindei wrote: > 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? +1 for the name not being a String. Today in OGM we use a generic Key object to represent associations. A string version has many drawbacks. ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Dropping AtomicMap/FineGrainedAtomicMap
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. 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... Cheers Dan On Wed, Jan 22, 2014 at 2:45 PM, Mircea Markus wrote: > > On Jan 21, 2014, at 8:42 PM, Vladimir Blagojevic > 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@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Dropping AtomicMap/FineGrainedAtomicMap
On Jan 21, 2014, at 8:42 PM, Vladimir Blagojevic 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@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Dropping AtomicMap/FineGrainedAtomicMap
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. > > Erik > ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Dropping AtomicMap/FineGrainedAtomicMap
Please don't remove the Delta stuff. That's quite useful, especially for large collections. Erik -Original Message- From: infinispan-dev-boun...@lists.jboss.org [mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Pedro Ruivo Sent: Monday, January 20, 2014 6:33 AM To: infinispan-dev@lists.jboss.org Subject: Re: [infinispan-dev] Dropping AtomicMap/FineGrainedAtomicMap Hi, On 01/20/2014 11:28 AM, Galder Zamarreño wrote: > Hi all, > > Dropping AtomicMap and FineGrainedAtomicMap was discussed last week in the F2F meeting [1]. It's complex and buggy, and we'd recommend people to use the Grouping API instead [2]. Grouping API would allow data to reside together, while the standard map API would apply per-key locking. +1. are we going to dropping the Delta stuff? > > We don't have a timeline for this yet, but we want to get as much feedback on the topic as possible so that we can evaluate the options. before starting with it, I would recommend to add the following method to cache API: /** * returns all the keys and values associated with the group name. The Map is immutable (i.e. read-only) **/ Map getGroup(String groupName); Cheers, Pedro > > Cheers, > > [1] https://issues.jboss.org/browse/ISPN-3901 > [2] > http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_the_group > ing_api > -- > Galder Zamarreño > gal...@redhat.com > twitter.com/galderz > > Project Lead, Escalante > http://escalante.io > > Engineer, Infinispan > http://infinispan.org > > > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Dropping AtomicMap/FineGrainedAtomicMap
On Jan 20, 2014, at 11:28 AM, Galder Zamarreño wrote: > Hi all, > > Dropping AtomicMap and FineGrainedAtomicMap was discussed last week in the > F2F meeting [1]. It's complex and buggy, and we'd recommend people to use the > Grouping API instead [2]. Grouping API would allow data to reside together, > while the standard map API would apply per-key locking. > > We don't have a timeline for this yet, but we want to get as much feedback on > the topic as possible so that we can evaluate the options. +1 There's been a good discussion on this topic: http://goo.gl/WNs6KY > > Cheers, > > [1] https://issues.jboss.org/browse/ISPN-3901 > [2] > http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_the_grouping_api > -- > Galder Zamarreño > gal...@redhat.com > twitter.com/galderz > > Project Lead, Escalante > http://escalante.io > > Engineer, Infinispan > http://infinispan.org > > > ___ > infinispan-dev mailing list > infinispan-dev@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Dropping AtomicMap/FineGrainedAtomicMap
Then cf the detailed feedback from that mailing list from the last time we discussed it :) There was specifically some feedback on how we use it for OGM and how we need a way to retrieve all entries for a given group (at least). Emmanuel On Mon 2014-01-20 12:28, Galder Zamarreño wrote: > Hi all, > > Dropping AtomicMap and FineGrainedAtomicMap was discussed last week in the > F2F meeting [1]. It's complex and buggy, and we'd recommend people to use the > Grouping API instead [2]. Grouping API would allow data to reside together, > while the standard map API would apply per-key locking. > > We don't have a timeline for this yet, but we want to get as much feedback on > the topic as possible so that we can evaluate the options. > > Cheers, > > [1] https://issues.jboss.org/browse/ISPN-3901 > [2] > http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_the_grouping_api > -- > Galder Zamarreño > gal...@redhat.com > twitter.com/galderz > > Project Lead, Escalante > http://escalante.io > > Engineer, Infinispan > http://infinispan.org > > > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Dropping AtomicMap/FineGrainedAtomicMap
Hi, On 01/20/2014 11:28 AM, Galder Zamarreño wrote: > Hi all, > > Dropping AtomicMap and FineGrainedAtomicMap was discussed last week in the > F2F meeting [1]. It's complex and buggy, and we'd recommend people to use the > Grouping API instead [2]. Grouping API would allow data to reside together, > while the standard map API would apply per-key locking. +1. are we going to dropping the Delta stuff? > > We don't have a timeline for this yet, but we want to get as much feedback on > the topic as possible so that we can evaluate the options. before starting with it, I would recommend to add the following method to cache API: /** * returns all the keys and values associated with the group name. The Map is immutable (i.e. read-only) **/ Map getGroup(String groupName); Cheers, Pedro > > Cheers, > > [1] https://issues.jboss.org/browse/ISPN-3901 > [2] > http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_the_grouping_api > -- > Galder Zamarreño > gal...@redhat.com > twitter.com/galderz > > Project Lead, Escalante > http://escalante.io > > Engineer, Infinispan > http://infinispan.org > > > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] Dropping AtomicMap/FineGrainedAtomicMap
Hi all, Dropping AtomicMap and FineGrainedAtomicMap was discussed last week in the F2F meeting [1]. It's complex and buggy, and we'd recommend people to use the Grouping API instead [2]. Grouping API would allow data to reside together, while the standard map API would apply per-key locking. We don't have a timeline for this yet, but we want to get as much feedback on the topic as possible so that we can evaluate the options. Cheers, [1] https://issues.jboss.org/browse/ISPN-3901 [2] http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_the_grouping_api -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
