Morten Jorgensen created CASSANDRA-7534:
-------------------------------------------

             Summary: TTL on rows to ensure data consistency
                 Key: CASSANDRA-7534
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7534
             Project: Cassandra
          Issue Type: Improvement
          Components: Core
            Reporter: Morten Jorgensen
             Fix For: 3.0


Requesting TTL on key/row-level to ensure consistency between data stored in 
columns under the same key. Please refer to original request for this 
enhancement in CASSANDRA-2469.

There are valid reasons why you would want the TTL on the key/row rather than 
the individual columns. The reason why you store your data as columns under a 
common key is that the data is related, and hence you want to ensure that all 
data exists as long as the key exists. Example:

I have developed a plugin for Tomcat that stores user session data in 
Cassandra, effectively making Tomcat stateless (and scalable) even if it 
maintains user sessions. Session data is stored in Cassandra under the session 
ID (key/row), as session attribute name/value-pairs (columns). Sessions time 
out after N minutes of inactivity, and I would prefer to use Cassandra's TTL 
for this. Otherwise I have to traverse all sessions periodically and purge 
sessions that are past their expiry time. But, the problem using the 
column-level TTL is that I risk timing out only parts of a user session, rather 
than all of it. So, a user that accesses JSPs that require read/write access to 
only certain session objects will retain those objects in Cassandra, while 
other session objects will expire with their respective column TTL's. This 
creates an inconsistent session, with some data expiring and some data 
remaining in the session - while what I need is the entire session to remain or 
expire as a whole.

This is one valid use case for key-level TTL, and this is only one specific 
example of the more general use case of column consistency. I suggest that this 
issue is re-opened an re-evaluated from this perspective.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to