without a clear description of your pseudo-code, it's difficult to say
whether it will work.
but I think it can work fine as an election/agreement protocol, which you
can use as a lock to some degree, but this requires
all the potential lock contenders to all participate, you can't grab a lock
before everyone has voiced their vote yet
. let's say the code is like
lock(UUID) {
write_column( "token_"+my_hostname()+"_"+UUID, getTimeStamp() );
for all possible node N :
block until ( token = read_column("token_" + N + "_" + UUID,
getTimeStamp()) ) != null
return "LOCKED" if my timestamp is the lowest among all nodes
}
you have to wait for all nodes to voice their timestamp because the
timestamp in cassandra is client-generated, a latter node can create a
column with an earlier
timestamp.
On Fri, Jun 24, 2011 at 11:33 AM, AJ <[email protected]> wrote:
> Sorry, I know this is long-winded but I just want to make sure before I go
> through the trouble to implement this since it's not something that can be
> reliably tested and requires in-depth knowledge about C* internals. But,
> this ultimately deals with concurrency control so anyone interested in that
> subject may want to try and answer this. Thanks!
>
>
> I would like to know how to do a series of writes and reads such that I can
> tell definitively what process out of many was the first to create a unique
> flag column.
>
> IOW, I would like to have multiple processes (clients) compete to see who
> is first to write a token column. The tokens start with a known prefix,
> such as "Token_" followed by the name of the process that created it and a
> UUID so that all columns are guaranteed unique and don't get overwritten.
> For example, Process A could create:
>
> Token_ProcA_<UUID>
>
> and process B would create:
>
> Token_ProcB_<UUID>
>
> These writes/reads are asynchronous between the two or more processes.
> After the two processes write their respective tokens, each will read back
> all columns named "Token_*" that exist (a slice). They each do this in
> order to find out who "won". The process that wrote the column with the
> lowest timestamp wins. The purpose is to implement a lock.
>
> I think all that is required is for the processes to use QUORUM read/writes
> to make sure the final read is consistent and will assure each process that
> it can rely on what's returned from the final read and that there isn't an
> earlier write floating around somewhere. This is where the
> "happened-before" question comes in. Is it possible that Process A which
> writes it's token with a lower timestamp (and should be the winner), that
> this write may not be seen by Process B when it does it's read (which is
> after it's token write and after Process A wrote it's token), and thus
> conclude incorrectly that itself (Process B) is the winner since it will not
> see Process A's token? I'm 99% sure using QUORUM read/writes will allow
> this to work because that's the whole purpose, but I just wanted to
> double-check in case there's another detail I'm forgetting about C* that
> would defeat this.
>
> Thanks!
>
> P.S. I realize this will cost me in performance, but this is only meant to
> be used on occasion.
>
