The solution outlined on the jira looks good to me.
Sent from my mobile phone
On 11 May 2011, at 10:58, Mircea Markus mircea.mar...@jboss.com wrote:
Hi,
I've added a possible solution to https://issues.jboss.org/browse/ISPN-1049,
can you please take a look and tell me what you think?
Hi Paolo - I'll ping you off-list with these details.
On 29 Apr 2011, at 18:47, Paolo Romano wrote:
Hi guys,
we're preparing a paper describing the self-tuning replication mechanism
(Primary backup vs the 2PC-based replication mechanism currently used by
Infinispan), and we'd like to
Hello all,
as some of us met recently at events, we've been discussing some
details about the current locking implementations and possible
improvements.
Some interesting ideas came out and we've been writing them down on
the wiki so that everyone can be involved:
On 29 Apr 2011, at 19:36, Sanne Grinovero wrote:
2011/4/29 Israel Lacerra israe...@gmail.com:
What about use D) and also give a way to user specify the default classes to
all queries?
Yes that's the idea; but we need to figure out how the user specifies
the default classes; so far nobody
Have we got a JIRA for this BTW?
On 2 May 2011, at 08:16, Galder Zamarreño wrote:
+1 to limiting to named cache components
On Apr 29, 2011, at 7:23 PM, Manik Surtani wrote:
I think any log attached to a named cache component (versus a global
component) should present cache name.
--
Thanks for this.
One of the things Sanne and I discussed is eventing and whether we really need
events over Hot Rod, and how urgent this is. For the JBW keynote demo we
effectively mimicked the same by using JMS. I.e., listeners on the remote
notes putting interesting events on a topic which
On 5/12/11 4:18 AM, Dan Berindei wrote:
On Wed, May 11, 2011 at 11:18 PM, David Bosschaertda...@redhat.com wrote:
On 11/05/2011 17:54, Dan Berindei wrote:
On Wed, May 11, 2011 at 7:08 PM, Pete Muirpm...@redhat.comwrote:
Were we developing for OSGi I would certainly agree with you. However
Yes, please have a look. If we are relying on lock upgrades then that's really
bad. I am aware of the inability to (safely) upgrade a RWL and I'm pretty sure
we don't try, but the dist sync codebase has evolved a lot and could do with
some careful analysis.
Sent from my mobile phone
On 12
Yes, collocation of all keys is a large concern of my application(s).
Currently, I can handle keys I'm in control of (like database-generated keys),
where I can play around with the hash code. What I would love to do is
collocate that data with keys I can't control (like UUIDs) so that all
On Fri, May 13, 2011 at 6:38 PM, Erik Salter esal...@bnivideo.com wrote:
Yes, collocation of all keys is a large concern of my application(s).
Currently, I can handle keys I'm in control of (like database-generated
keys), where I can play around with the hash code. What I would love to do
Hi Dan,
I don't necessarily care about which server it's on, as long as the keys for my
set of caches all remain collocated. I understand they will all end up in the
same bucket, but for one hash code, that's at most 200 keys. I must acquire a
lock for a subset of them during a transaction
On Fri, May 13, 2011 at 5:48 PM, Jason T. Greene
jason.gre...@redhat.com wrote:
On 5/12/11 4:18 AM, Dan Berindei wrote:
On Wed, May 11, 2011 at 11:18 PM, David Bosschaertda...@redhat.com
wrote:
On 11/05/2011 17:54, Dan Berindei wrote:
On Wed, May 11, 2011 at 7:08 PM, Pete
2011/5/13 Manik Surtani ma...@jboss.org:
On 29 Apr 2011, at 19:36, Sanne Grinovero wrote:
2011/4/29 Israel Lacerra israe...@gmail.com:
What about use D) and also give a way to user specify the default classes to
all queries?
Yes that's the idea; but we need to figure out how the user
13 matches
Mail list logo
