incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Lebresne <sylv...@datastax.com>
Subject Re: Mixing CAS and TTL.
Date Tue, 25 Feb 2014 11:12:41 GMT
You're running into https://issues.apache.org/jira/browse/CASSANDRA-6623.
It will be fixed in 2.0.6 but you can read the comments there for more
details.


On Tue, Feb 25, 2014 at 9:02 AM, J Robert Ray <jrobertray@gmail.com> wrote:

> Thanks Daniel.
>
> I am taking care to only expire the one column. There are other columns so
> my row isn't completely deleted.
> On Feb 24, 2014 11:37 PM, "Daniel Shelepov" <daniel@timefork.com> wrote:
>
>> For the case where you don't get the update, is your whole row removed
>> when TTL expires?  If so, you're essentially looking at a non-existing row,
>> and I think it's not too surprising that a "if col=null" test will behave
>> differently; I personally wouldn't call it a bug.  If you're dealing with
>> disappearing rows, you should look into running INSERT IF NOT EXISTS
>> queries instead of UPDATE IF col=null.
>>
>>
>>
>> If the row is not completely deleted when TTL expires, then the behavior
>> is definitely fishy, and should probably be filed as a bug.
>>
>>
>>
>> To your other question, once a TTL update is expired, you can't infer its
>> past existence through any queries.
>>
>>
>>
>> Daniel
>>
>>
>>
>> *From:* J Robert Ray [mailto:jrobertray@gmail.com]
>> *Sent:* Monday, February 24, 2014 11:10 PM
>> *To:* user@cassandra.apache.org
>> *Subject:* Mixing CAS and TTL.
>>
>>
>>
>> Hi, I am trying to mix CAS and TTL and am wondering if this behavior that
>> I am seeing is expected.
>>
>>
>>
>> I'm on 2.0.2 and using the java datastax 2.0.0-rc3 client.
>>
>>
>>
>> In my application, a server "claims" a row by assigning a value to a row
>> using CAS, expecting the column to start out null. The column has a
>> shortish TTL and while the application "owns" the row, it will periodically
>> refresh the TTL on the column. If the application dies, the column expires
>> and can be claimed by another server. My problem is that after the TTL
>> expires, no server can successfully claim a row using a CAS update.
>>
>>
>>
>> If I set a TTL on a column with a null value (for demonstration purposes;
>> the real code sets to a non-null value):
>>
>>
>>
>> UPDATE foo USING TTL 120 SET col = null WHERE ...;
>>
>>
>>
>> This CAS update will succeed:
>>
>>
>>
>> UPDATE foo USING TTL 120 SET col = 'some value' IF col = null; //
>> [applied] = true
>>
>> or
>>
>> UPDATE foo USING TTL 120 SET col = 'some value' IF col = 'foo'; //
>> [applied] = true, col = null
>>
>>
>>
>> However, if I allow the TTL to expire, then the same update now fails.
>>
>>
>>
>> UPDATE foo USING TTL 120 SET col = 'some value' IF col = null; //
>> [applied] = false
>>
>>
>>
>> Note, after it fails, the ResultSet column definitions only contains
>> "[applied]" and so does not provide the value of the 'col' column which
>> failed the conditional update.
>>
>>
>>
>> It seems a null value is a different flavor of null than an expired
>> column. Is it possible to make an update conditional on if a column is
>> expired? Is this behavior expected or a bug?
>>
>>
>>
>> Thanks!
>>
>

Mime
View raw message