<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPhone</div><div><br>On 22 Jan 2014, at 13:58, Dan Berindei <<a href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 21, 2014 at 4:07 PM, Mircea Markus <span dir="ltr"><<a href="mailto:mmarkus@redhat.com" target="_blank">mmarkus@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Emmanuel,<br>
<br>
Just had a good chat with Davide on this and one solution to overcome the shortcoming you mentioned in the above email would be to enhance the hotrod client to support grouping:<br>
<br>
RemoteClient.put(G g, K k, V v); //first param is the group<br>
RemoteClinet.getGroup(G g) : Map<K,V>;<br></blockquote><div><br></div><div>I think you'd also need RemoteClient.get(G g, K k), as in embedded mode the group is included in the key.<br></div></div></div></div></div></blockquote><div><br></div><div>Yes</div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
</blockquote><div><br></div><div>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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This approach still has some limitations compared to the current embedded integration:<br>
- performance caused by the lack of transactions: this means increased TCP chattiness between the Hot Rod client and the server.<br>
- you'd have to handle atomicity, potentially by retrying an operation<br>
<br>
What do you think?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Dec 3, 2013, at 3:10 AM, Mircea Markus <<a href="mailto:mmarkus@redhat.com">mmarkus@redhat.com</a>> wrote:<br>
<br>
><br>
> On Nov 19, 2013, at 10:22 AM, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>> wrote:<br>
><br>
>> It's an interesting approach that would work fine-ish for entities<br>
>> assuming the Hot Rod client is multi threaded and assuming the client<br>
>> uses Future to parallelize the calls.<br>
><br>
> The Java Hotrod client is both multithreaded and exposes an Async API.<br>
><br>
>><br>
>> But it won't work for associations as we have them designed today.<br>
>> Each association - or more precisely the query results to go from an<br>
>> entity A1 to the list of entities B associated to it - is represented by<br>
>> an AtomicMap.<br>
>> Each entry in this map does correspond to an entry in the association.<br>
>><br>
>> While we can "guess" the column names and build from the metadata the<br>
>> list of composed keys for entities, we cannot do the same for<br>
>> associations as the key is literally the (composite) id of the<br>
>> association and we cannot guess that most of the time (we can in very<br>
>> pathological cases).<br>
>> We could imagine that we list the association row keys in a special<br>
>> entry to work around that but this approach is just as problematic and<br>
>> is conceptually the same.<br>
>> The only solution would be to lock the whole association for each<br>
>> operation and I guess impose some versioning / optimistic lock.<br>
>><br>
>> That is not a pattern that scales sufficiently from my experience.<br>
><br>
> I think so too :-)<br>
><br>
>> That's the problem with interconnected data :)<br>
>><br>
>> Emmanuel<br>
>><br>
>> On Mon 2013-11-18 23:05, Mircea Markus wrote:<br>
>>> Neither the grouping API nor the AtomicMap work over hotrod.<br>
>>> Between the grouping API and AtomicMap, I think the one that would make more sense migrating is the grouping API.<br>
>>> One way or the other, I think the hotrod protocol would require an enhancement - mind raising a JIRA for that?<br>
>>> For now I guess you can sacrifice performance and always sending the entire object across on every update instead of only the deltas?<br>
>>><br>
>>> On Nov 18, 2013, at 9:56 AM, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>> wrote:<br>
>>><br>
>>>> Someone mentioned the grouping API as some sort of alternative to<br>
>>>> AtomicMap. Maybe we should use that?<br>
>>>> Note that if we don't have a fine-grained approach we will need to<br>
>>>> make sure we *copy* the complex data structure upon reads to mimic<br>
>>>> proper transaction isolation.<br>
>>>><br>
>>>> On Tue 2013-11-12 15:14, Sanne Grinovero wrote:<br>
>>>>> On 12 November 2013 14:54, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>> wrote:<br>
>>>>>> On the transaction side, we can start without them.<br>
>>>>><br>
>>>>> +1 on omitting transactions for now.<br>
>>>>><br>
>>>>> And on the missing AtomicMaps, I hope the Infinispan will want to implement it?<br>
>>>>> Would be good to eventually converge on similar featuresets on remote<br>
>>>>> vs embedded APIs.<br>
>>>>><br>
>>>>> I know the embedded version relies on batching/transactions, but I<br>
>>>>> guess we could obtain a similar effect with some ad-hoc commands in<br>
>>>>> Hot Rod?<br>
>>>>><br>
>>>>> Sanne<br>
>>>>><br>
>>>>>><br>
>>>>>> On Tue 2013-11-12 14:34, Davide D'Alto wrote:<br>
>>>>>>> Hi,<br>
>>>>>>> I'm working on the integration between HotRod and OGM.<br>
>>>>>>><br>
>>>>>>> We already have a dialect for Inifinispan and I'm trying to follow the same<br>
>>>>>>> logic.<br>
>>>>>>> At the moment I'm having two problems:<br>
>>>>>>><br>
>>>>>>> 1) In the Infinispan dialect we are using the AtomicMap and the<br>
>>>>>>> AtomicMapLookup but this classes don't work with the RemoteCache. Is there<br>
>>>>>>> an equivalent for HotRod?<br>
>>>>>>><br>
>>>>>>> 2) As far as I know HotRod does not support transactions. I've found a link<br>
>>>>>>> to a branch on Mircea repository:<br>
>>>>>>> <a href="https://github.com/mmarkus/ops_over_hotrod/wiki/Usage-guide" target="_blank">https://github.com/mmarkus/ops_over_hotrod/wiki/Usage-guide</a><br>
>>>>>>> Is this something I could/should use?<br>
>>>>>>><br>
>>>>>>> Any help is appreciated.<br>
>>>>>>><br>
>>>>>>> Thanks,<br>
>>>>>>> Davide<br>
>>>>>><br>
>>>>>>> _______________________________________________<br>
>>>>>>> infinispan-dev mailing list<br>
>>>>>>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> infinispan-dev mailing list<br>
>>>>>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>>>>> _______________________________________________<br>
>>>>> infinispan-dev mailing list<br>
>>>>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>>>> _______________________________________________<br>
>>>> infinispan-dev mailing list<br>
>>>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>>><br>
>>> Cheers,<br>
>>> --<br>
>>> Mircea Markus<br>
>>> Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> infinispan-dev mailing list<br>
>>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>> _______________________________________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
> Cheers,<br>
> --<br>
> Mircea Markus<br>
> Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
><br>
><br>
><br>
><br>
<br>
Cheers,<br>
--<br>
Mircea Markus<br>
Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>infinispan-dev mailing list</span><br><span><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></span></div></blockquote></body></html>