Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag

2013-06-06 Thread Ray Tsang
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

Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag

2013-06-06 Thread Mircea Markus
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. > >> > >>

Re: [infinispan-dev] Using infinispan as quorum-based nosql

2013-06-06 Thread Mircea Markus
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

[infinispan-dev] Infinispan 5.3.0.CR2

2013-06-06 Thread Mircea Markus
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

Re: [infinispan-dev] CHMv8 bugfix to be backported

2013-06-06 Thread Galder Zamarreño
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

[infinispan-dev] CHMv8 bugfix to be backported

2013-06-06 Thread Sanne Grinovero
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

Re: [infinispan-dev] Using infinispan as quorum-based nosql

2013-06-06 Thread vitalii.tymchyshyn
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

Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag

2013-06-06 Thread Galder Zamarreño
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: > > > >

Re: [infinispan-dev] Using infinispan as quorum-based nosql

2013-06-06 Thread Dan Berindei
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

Re: [infinispan-dev] Using infinispan as quorum-based nosql

2013-06-06 Thread vitalii.tymchyshyn
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