It requires an enhancement on our local grouping API: EmbeddedCache.getGroup(G). This is something useful for us in a broader context, as it is the step needed to be able to deprecated AtomicMaps and get suggest them being replaced with Grouping.

It would also require us to keep a Set<K> for each group, with the keys associated with that group. As such, I'm not sure it would be a lot easier to implement (correctly) than FineGrainedAtomicMap.

This approach still has some limitations compared to the current embedded integration:
- performance caused by the lack of transactions: this means increased TCP chattiness between the Hot Rod client and the server.
- you'd have to handle atomicity, potentially by retrying an operation

What do you think?

On Dec 3, 2013, at 3:10 AM, Mircea Markus <mmarkus@redhat.com> wrote:

>
> On Nov 19, 2013, at 10:22 AM, Emmanuel Bernard <emmanuel@hibernate.org> wrote:
>
>> It's an interesting approach that would work fine-ish for entities
>> assuming the Hot Rod client is multi threaded and assuming the client
>> uses Future to parallelize the calls.
>
> The Java Hotrod client is both multithreaded and exposes an Async API.
>
>>
>> But it won't work for associations as we have them designed today.
>> Each association - or more precisely the query results to go from an
>> entity A1 to the list of entities B associated to it - is represented by
>> an AtomicMap.
>> Each entry in this map does correspond to an entry in the association.
>>
>> While we can "guess" the column names and build from the metadata the
>> list of composed keys for entities, we cannot do the same for
>> associations as the key is literally the (composite) id of the
>> association and we cannot guess that most of the time (we can in very
>> pathological cases).
>> We could imagine that we list the association row keys in a special
>> entry to work around that but this approach is just as problematic and
>> is conceptually the same.
>> The only solution would be to lock the whole association for each
>> operation and I guess impose some versioning / optimistic lock.
>>
>> That is not a pattern that scales sufficiently from my experience.
>
> I think so too :-)
>
>> That's the problem with interconnected data :)
>>
>> Emmanuel
>>
>> On Mon 2013-11-18 23:05, Mircea Markus wrote:
>>> Neither the grouping API nor the AtomicMap work over hotrod.
>>> Between the grouping API and AtomicMap, I think the one that would make more sense migrating is the grouping API.
>>> One way or the other, I think the hotrod protocol would require an enhancement - mind raising a JIRA for that?
>>> For now I guess you can sacrifice performance and always sending the entire object across on every update instead of only the deltas?
>>>
>>> On Nov 18, 2013, at 9:56 AM, Emmanuel Bernard <emmanuel@hibernate.org> wrote:
>>>
>>>> Someone mentioned the grouping API as some sort of alternative to
>>>> AtomicMap. Maybe we should use that?
>>>> Note that if we don't have a fine-grained approach we will need to
>>>> make sure we *copy* the complex data structure upon reads to mimic
>>>> proper transaction isolation.
>>>>
>>>> On Tue 2013-11-12 15:14, Sanne Grinovero wrote:
>>>>> On 12 November 2013 14:54, Emmanuel Bernard <emmanuel@hibernate.org> wrote:
>>>>>> On the transaction side, we can start without them.
>>>>>
>>>>> +1 on omitting transactions for now.
>>>>>
>>>>> And on the missing AtomicMaps, I hope the Infinispan will want to implement it?
>>>>> Would be good to eventually converge on similar featuresets on remote
>>>>> vs embedded APIs.
>>>>>
>>>>> I know the embedded version relies on batching/transactions, but I
>>>>> guess we could obtain a similar effect with some ad-hoc commands in
>>>>> Hot Rod?
>>>>>
>>>>> Sanne
>>>>>
>>>>>>
>>>>>> On Tue 2013-11-12 14:34, Davide D'Alto wrote:
>>>>>>> Hi,
>>>>>>> I'm working on the integration between HotRod and OGM.
>>>>>>>
>>>>>>> We already have a dialect for Inifinispan and I'm trying to follow the same
>>>>>>> logic.
>>>>>>> At the moment I'm having two problems:
>>>>>>>
>>>>>>> 1) In the Infinispan dialect we are using the AtomicMap and the
>>>>>>> AtomicMapLookup but this classes don't work with the RemoteCache. Is there
>>>>>>> an equivalent for HotRod?
>>>>>>>
>>>>>>> 2) As far as I know HotRod does not support transactions. I've found a link
>>>>>>> to a branch on Mircea repository:
>>>>>>> https://github.com/mmarkus/ops_over_hotrod/wiki/Usage-guide
>>>>>>> Is this something I could/should use?
>>>>>>>
>>>>>>> Any help is appreciated.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Davide
>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>> _______________________________________________
>>>> 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
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.infinispan.org)
>
>
>
>

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