On Jun 6, 2013, at 13:26, Mircea Markus wrote:
>
> On 4 Jun 2013, at 13:55, Dan Berindei wrote:
>
CacheLoaderInterceptor and DistributionInterceptor both honour the
IGNORE_RETURN_VALUES flag for get commands, but I think it would be more
useful if they ignored it - just like the
On 4 Jun 2013, at 13:55, Dan Berindei wrote:
> >> CacheLoaderInterceptor and DistributionInterceptor both honour the
> >> IGNORE_RETURN_VALUES flag for get commands, but I think it would be more
> >> useful if they ignored it - just like they ignore it for conditional
> >> commands.
> >>
> >>
On 6 Jun 2013, at 10:09, Dan Berindei wrote:
> Say you have two transactions, tx1 and tx2. They both send a
> LockControlCommand(k1) to the primary owner of k1 (let's call it B).
> If the lock commands use SYNCHRONOUS_IGNORE_LEAVERS and B dies while
> processing the commands, both tx1 and tx2
Given the amount of pending fixed, I'm thinking to cut an 5.3.0.CR2 (last CR)
on Tue 11 June.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mail
On Jun 6, 2013, at 1:11 PM, Sanne Grinovero wrote:
> The concurrency-interest mailing list mentioned a bug in the CHMv8
> which could cause data loss, apparently a fix was applied already but
> I guess this doesn't magically appear in the Infinispan sources.
I spotted that I already created a j
The concurrency-interest mailing list mentioned a bug in the CHMv8
which could cause data loss, apparently a fix was applied already but
I guess this doesn't magically appear in the Infinispan sources.
I didn't create a JIRA as I haven't been able to look if the issue
affects our copy, or how crit
Well, I don't do SYNCHRONOUS_IGNORE_LEAVERS for commands that has less than
quorumSize number of destinations (so commands to single destination retain
it's ResponseMode unchanged) and recheck after the command that I still have
enough member in the cluster. But I will add a test to check that b
On Jun 4, 2013, at 2:55 PM, Dan Berindei wrote:
>
>
>
> On Tue, Jun 4, 2013 at 12:27 PM, Mircea Markus wrote:
>
> On 3 Jun 2013, at 19:01, Dan Berindei wrote:
>
> > Fair point... ok, let's leave it as it is now.
> >
> >
> > On Mon, Jun 3, 2013 at 5:23 PM, Galder Zamarreño wrote:
> >
> >
Say you have two transactions, tx1 and tx2. They both send a
LockControlCommand(k1) to the primary owner of k1 (let's call it B).
If the lock commands use SYNCHRONOUS_IGNORE_LEAVERS and B dies while
processing the commands, both tx1 and tx2 will think they have succeeded in
locking k1.
So you're r
Hello.
We are using pessimistic transaction mode. In this case everything's already
locked by the time of prepare, is not it?
As of merge, for quorum mode it's simple - take data from quorum. I think I
will try to simply suppress sending data from non-quorum members on merge.
Because currently
10 matches
Mail list logo