Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
Sender: scode@scode.org
In-Reply-To: <4CC08D51.9080405@gmail.com>
References: <4CBF99A8.7060304@dawningstreams.com>
	<AANLkTik1M1tcUGVY8ufAQUVb-pHUvGzNJWQN=uX=yqHF@mail.gmail.com>
	<4CBFB04E.6090406@gmail.com>
	<AANLkTi=C9SDT0LfvFwDQzCV4eGBjp8p95wObwzKpoWrw@mail.gmail.com>
	<4CC08D51.9080405@gmail.com>
Date: Thu, 21 Oct 2010 23:40:59 +0200
Message-ID: <AANLkTikRkn9gT+CF9VGNPRG+ia2LQXdAiYAmY7nVpN7D@mail.gmail.com>
Subject: Re: What happens if there is a collision?
From: Peter Schuller <peter.schuller@infidyne.com>
To: user@cassandra.apache.org
Cc: Jonathan Ellis <jbellis@gmail.com>
Content-Type: text/plain; charset=UTF-8

> OK. Thanks for your answer. From an email exchange I had with Jonathan, all
> this means that one should re-read its writes with quorum to make sure they
> have not been overriden by timestamp-tie conflicts. I suggested to send
> feedback to writting node (in the ACK) when such timestamps-tie conflict
> happen. This would avoid having to double-check all writes for timestamp-tie
> conflicts.
>
> If multiple applications write to the same ColumnFamily/Tables, this
> double-check is a must (unless a separate locking mecanism is implemented,
> which would be more heavy).

I'm not sure I understand what you're trying to accomplish. Given that
you have no locking/synchronization mechanism external to Cassandra,
what is it that you are actually learning from re-reading the value? A
completed write at level QUOROM means it was successfully written and
that readers reading at QUOROM will see it unless the value has been
updated subsequently. But even if you re-read, that does not remove
the fundamental potential for a race condition (i.e., you still don't
know when you see the result of your read whether it wasn't just
ovewritten anyway just after you did your read).

Perhaps I'm misunderstanding what you're trying to do?

-- 
/ Peter Schuller