On Jun 17, 2014, at 10:53, Galder Zamarreño gal...@redhat.com wrote:
On 16 Jun 2014, at 16:57, Dan Berindei dan.berin...@gmail.com wrote:
On Thu, Jun 12, 2014 at 4:54 PM, Galder Zamarreño gal...@redhat.com wrote:
Hi all,
I’m working on the implementation of this, and the solution noted
On Thu, Jun 12, 2014 at 4:54 PM, Galder Zamarreño gal...@redhat.com wrote:
Hi all,
I’m working on the implementation of this, and the solution noted in the
JIRA does not work for situations where you have to return a previous value
that might have been overriden due to partial operation
Hi all,
I’m working on the implementation of this, and the solution noted in the JIRA
does not work for situations where you have to return a previous value that
might have been overriden due to partial operation application. Example
(assuming 1 owner only):
1. remote client does a put(“key”,
On May 13, 2014, at 14:58, Dan Berindei dan.berin...@gmail.com wrote:
On Mon, May 12, 2014 at 1:54 PM, Radim Vansa rva...@redhat.com wrote:
@Dan: It's absolutely correct to do the further writes in order to make
the cache consistent, I am not arguing against that. You've fixed the
Hi all,
I’ve been looking into ISPN-2956 last week and I think we have a solution for
it which requires a protocol change [1]
Since we’re in the middle of the Hot Rod 2.0 development, this is a good
opportunity to implement it.
Cheers,
[1]
On Tue, May 13, 2014 at 6:40 PM, Radim Vansa rva...@redhat.com wrote:
On 05/13/2014 03:58 PM, Dan Berindei wrote:
On Mon, May 12, 2014 at 1:54 PM, Radim Vansa rva...@redhat.com wrote:
@Dan: It's absolutely correct to do the further writes in order to make
the cache consistent, I am not
On Mon, May 12, 2014 at 1:54 PM, Radim Vansa rva...@redhat.com wrote:
@Dan: It's absolutely correct to do the further writes in order to make
the cache consistent, I am not arguing against that. You've fixed the
outcome (state of cache) well. My point was that we should let the user
know that
I didn't mean to suggest any solution, just that it should be fixed ..
anyway you like :)
If versions are needed, so be it.. but I didn't think it through.
Cheers,
Sanne
On 13 May 2014 14:58, Dan Berindei dan.berin...@gmail.com wrote:
On Mon, May 12, 2014 at 1:54 PM, Radim Vansa
On 05/13/2014 03:58 PM, Dan Berindei wrote:
On Mon, May 12, 2014 at 1:54 PM, Radim Vansa rva...@redhat.com
mailto:rva...@redhat.com wrote:
@Dan: It's absolutely correct to do the further writes in order to
make
the cache consistent, I am not arguing against that. You've fixed
Hi,
recently I've stumbled upon one already expected behaviour (one instance
is [1]), but which did not got much attention.
In non-tx cache, when the primary owner fails after the request has been
replicated to backup owner, the request is retried in the new topology.
Then, the operation is
Radim, I would contend that the first and foremost guarantee that put()
makes is to leave the cache in a consistent state. So we can't just throw
an exception and give up, leaving k=v on one owner and k=null on another.
Secondly, put(k, v) being atomic means that it either succeeds, it writes
k=v
I don't think we are in a position to decide what is a reasonable
compromise; we can do better.
For example - as Radim suggested - it might seem reasonable to have
the older value around for a little while. We'll need a little bit of
history of values and tombstones anyway for many other reasons.
@Dan: It's absolutely correct to do the further writes in order to make
the cache consistent, I am not arguing against that. You've fixed the
outcome (state of cache) well. My point was that we should let the user
know that the value he gets is not 100% correct when we already know
that - and
13 matches
Mail list logo
