On 11/21/2013 05:09 PM, Dan Berindei wrote:
On Thu, Nov 21, 2013 at 5:39 PM, Pedro Ruivo pe...@infinispan.org
mailto:pe...@infinispan.org wrote:
On 11/21/2013 03:18 PM, Dan Berindei wrote:
Hmm, couldn't you just disable recovery in the TM to get the same
performance with a
On 11/21/2013 10:08 PM, Sanne Grinovero wrote:
Hi Pedro,
great analysis.
Conceptually I agree, and since I'm not too familiar with the core
code, I actually expected this to be the case as we discussed the
approach when we first discussed the single-lock-owner pattern.
More specifically
On 22 November 2013 11:31, Pedro Ruivo pe...@infinispan.org wrote:
On 11/21/2013 10:08 PM, Sanne Grinovero wrote:
Hi Pedro,
great analysis.
Conceptually I agree, and since I'm not too familiar with the core
code, I actually expected this to be the case as we discussed the
approach when we
I wonder if we are over analyzing this. It seems the main issue is
that the replication is done asynchronously. Infinispan has many ways
to be make something asynchronous. In my opinion we just chose the
wrong way. Wouldn't it be easier to just change the PFER to instead
of passing along the
That doesn't sound right, we don't keep any lock for the duration of the
replication. In non-tx mode, we have to do a RPC to the primary owner
before we acquire any key. So there's nothing stopping the PFER from
writing its value after a regular (sync) put when the put was initiated
after the
On Fri, Nov 22, 2013 at 10:26 AM, Radim Vansa rva...@redhat.com wrote:
On 11/21/2013 05:09 PM, Dan Berindei wrote:
On Thu, Nov 21, 2013 at 5:39 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 11/21/2013 03:18 PM, Dan Berindei wrote:
Hmm, couldn't you just disable recovery in the TM to
During my presentation last week[1] Bela requested more information on how
the decoupled approach works. I have prepared a document[2] that explains
the decoupled approach in detail, from the perspective of an ordering box
member and an Infinispan node. This document assumes that the reader is
I've tidied my previous commit a bit and created JIRA:
https://issues.jboss.org/browse/ISPN-3750
I'm leaving out the CLI changes for the time being. With this the commit
is really small, unintrusive and easy to review...
https://github.com/mlinhard/infinispan/tree/t_ispn_3750
I'm not sure how
I think I need to clarify my earlier email a bit: the problem I'm worried
about is that we could have a thread execute a putForExternalLeave(k, v1),
then a put(k, v2), then a remove(k), and in the end leaving k = v1 in the
cache. (Without the remove(k) we'd be ok, because PFER uses putIfAbsent()
Hi,
I took a look at the document and these are my comments :)
(note: I only have the basic knowledge of security: security is a myth)
* About the permissions
It would be good to describe what is the relation between the
permissions. For example, answer the following question: can a
On 11/22/2013 03:39 PM, Dan Berindei wrote:
I think I need to clarify my earlier email a bit: the problem I'm
worried about is that we could have a thread execute a
putForExternalLeave(k, v1), then a put(k, v2), then a remove(k), and in
the end leaving k = v1 in the cache. (Without the
On Fri, Nov 22, 2013 at 10:51 AM, Pedro Ruivo pe...@infinispan.org wrote:
On 11/22/2013 03:39 PM, Dan Berindei wrote:
I think I need to clarify my earlier email a bit: the problem I'm
worried about is that we could have a thread execute a
putForExternalLeave(k, v1), then a put(k, v2), then a
On 11/22/2013 11:40 AM, Sanne Grinovero wrote:
Do we still need to support the non-V8 implementations?
Clearly there are cases in which we need it to be available:
org.infinispan.util.concurrent.locks.containers.AbstractPerEntryLockContainerL
refers explicitly to
On 11/22/2013 04:47 PM, Pedro Ruivo wrote:
* About the permissions
It would be good to describe what is the relation between the
permissions. For example, answer the following question: can a
user/group/role have READ permission over a cache without ACCESS
permission? Can it have WRITE
14 matches
Mail list logo
