On 23 January 2014 18:03, Dan Berindei dan.berin...@gmail.com wrote:
On 22 Jan 2014 16:10, Pedro Ruivo pe...@infinispan.org wrote:
On 01/22/2014 01:58 PM, Dan Berindei wrote:
It would also require us to keep a SetK for each group, with the keys
associated with that group. As such,
On 01/27/2014 09:20 AM, Sanne Grinovero wrote:
On 23 January 2014 18:03, Dan Berindei dan.berin...@gmail.com wrote:
On 22 Jan 2014 16:10, Pedro Ruivo pe...@infinispan.org wrote:
On 01/22/2014 01:58 PM, Dan Berindei wrote:
It would also require us to keep a SetK for each group, with the
On 27 January 2014 09:38, Pedro Ruivo pe...@infinispan.org wrote:
On 01/27/2014 09:20 AM, Sanne Grinovero wrote:
On 23 January 2014 18:03, Dan Berindei dan.berin...@gmail.com wrote:
On 22 Jan 2014 16:10, Pedro Ruivo pe...@infinispan.org wrote:
On 01/22/2014 01:58 PM, Dan Berindei wrote:
On 01/27/2014 09:52 AM, Sanne Grinovero wrote:
On 27 January 2014 09:38, Pedro Ruivo pe...@infinispan.org wrote:
On 01/27/2014 09:20 AM, Sanne Grinovero wrote:
On 23 January 2014 18:03, Dan Berindei dan.berin...@gmail.com wrote:
On 22 Jan 2014 16:10, Pedro Ruivo pe...@infinispan.org
I'd be curious to see performance tests on Pedro's approach (ie walk
through the entire data key set to find the matching elements of a given
group). That might be fast enough but that looks quite scary compared to
a single lookup.
Any doc explaining how FGAM is broken in transactions for
On 01/27/2014 12:26 PM, Emmanuel Bernard wrote:
I'd be curious to see performance tests on Pedro's approach (ie walk
through the entire data key set to find the matching elements of a given
group). That might be fast enough but that looks quite scary compared to
a single lookup.
I would
On Mon, Jan 27, 2014 at 2:43 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 01/27/2014 12:26 PM, Emmanuel Bernard wrote:
I'd be curious to see performance tests on Pedro's approach (ie walk
through the entire data key set to find the matching elements of a given
group). That might be
On 01/27/2014 01:38 PM, Dan Berindei wrote:
On Mon, Jan 27, 2014 at 2:43 PM, Pedro Ruivo pe...@infinispan.org
mailto:pe...@infinispan.org wrote:
On 01/27/2014 12:26 PM, Emmanuel Bernard wrote:
I'd be curious to see performance tests on Pedro's approach (ie walk
through
On Jan 27, 2014, at 1:38 PM, Dan Berindei dan.berin...@gmail.com wrote:
On Mon, Jan 27, 2014 at 2:43 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 01/27/2014 12:26 PM, Emmanuel Bernard wrote:
I'd be curious to see performance tests on Pedro's approach (ie walk
through the entire
On Jan 27, 2014, at 2:02 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 01/27/2014 01:38 PM, Dan Berindei wrote:
On Mon, Jan 27, 2014 at 2:43 PM, Pedro Ruivo pe...@infinispan.org
mailto:pe...@infinispan.org wrote:
On 01/27/2014 12:26 PM, Emmanuel Bernard wrote:
I'd be curious
On 22 Jan 2014 16:10, Pedro Ruivo pe...@infinispan.org wrote:
On 01/22/2014 01:58 PM, Dan Berindei wrote:
It would also require us to keep a SetK 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
Conceptually I like the grouping API better than AtomicMap as I don’t have to
rely on a specific Infinispan type.
We do use FineGrainedAtomicMap both for the entity and the association
persistence (not AtomicMap). It is particularly critical for how we store the
association navigation
On Jan 22, 2014, at 1:26 PM, Emmanuel Bernard emman...@hibernate.org wrote:
Conceptually I like the grouping API better than AtomicMap as I don’t have to
rely on a specific Infinispan type.
We do use FineGrainedAtomicMap both for the entity and the association
persistence (not
On Tue, Jan 21, 2014 at 4:07 PM, Mircea Markus mmar...@redhat.com wrote:
Hi Emmanuel,
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:
RemoteClient.put(G g, K k,
On 22 Jan 2014, at 14:48, Mircea Markus mmar...@redhat.com wrote:
On Jan 22, 2014, at 1:26 PM, Emmanuel Bernard emman...@hibernate.org wrote:
Conceptually I like the grouping API better than AtomicMap as I don’t have
to rely on a specific Infinispan type.
We do use
On 01/22/2014 01:58 PM, Dan Berindei wrote:
It would also require us to keep a SetK 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.
Dan, I didn't understand why do we need to keep
On 22 Jan 2014, at 15:11, Emmanuel Bernard emman...@hibernate.org wrote:
So you don't use the AtomicMap(vs FGAM) at all? Is there any place in which
you require a lock in the whole map to be acquired?
I will be not right now.
Hum, it should read: It will be. But not right
Hi Emmanuel,
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:
RemoteClient.put(G g, K k, V v); //first param is the group
RemoteClinet.getGroup(G g) : MapK,V;
It
Hi Mircea,
could you explain how Grouping is different than AtomicMaps ?
I understand you're all suggesting to move to AtomicMaps as the
implementation is better but is that an implementation detail, or how
is it inherently different so that we can build something more
reliable on it?
From the
On Jan 21, 2014, at 4:08 PM, Sanne Grinovero sa...@infinispan.org wrote:
Hi Mircea,
could you explain how Grouping is different than AtomicMaps ?
Here's the original thread where this has been discussed: http://goo.gl/WNs6KY
I would add to that that the AtomicMap requires transactions, which
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.
But it won't work for associations as we have them designed today.
Each association - or more precisely the query results
This message was a response to a different email discussing the composite
key approach k1 - a1 k1 - a2.
The actual JIRAs are opened :
* https://issues.jboss.org/browse/ISPN-3732
* https://issues.jboss.org/browse/ISPN-3733
Emmanuel
On Tue 2013-11-19 11:22, Emmanuel Bernard wrote:
It's an
We could rely on remote queries?
On 19 November 2013 10:31, Emmanuel Bernard emman...@hibernate.org wrote:
This message was a response to a different email discussing the composite
key approach k1 - a1 k1 - a2.
The actual JIRAs are opened :
* https://issues.jboss.org/browse/ISPN-3732
*
We could if someone puts a gun to my head.
But that would be the *only* backend that has to rely on query for its
association. Hibernate OGM has a strong design bias towards totally
controlling how CRUD is done to guarantee the consistency. If you
introduce a search engine, all bets are off.
On
On 19 November 2013 12:56, Emmanuel Bernard emman...@hibernate.org wrote:
We could if someone puts a gun to my head.
But that would be the *only* backend that has to rely on query for its
association. Hibernate OGM has a strong design bias towards totally
controlling how CRUD is done to
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
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
On 18 November 2013 23:05, Mircea Markus mmar...@redhat.com 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
On Nov 18, 2013, at 11:52 PM, Sanne Grinovero sa...@infinispan.org 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
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
On the transaction side, we can start without them.
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
On 12 November 2013 14:54, Emmanuel Bernard emman...@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
32 matches
Mail list logo
