incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Robert Ray <jrobert...@gmail.com>
Subject Re: Mixing CAS and TTL.
Date Tue, 25 Feb 2014 16:14:59 GMT
Good to hear, thanks. I didn't find that in my searches.
On Feb 25, 2014 3:13 AM, "Sylvain Lebresne" <sylvain@datastax.com> wrote:

> 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