[jira] [Commented] (CASSANDRA-2469) TTL on rows
[ https://issues.apache.org/jira/browse/CASSANDRA-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058620#comment-14058620 ] Morten Jorgensen commented on CASSANDRA-2469: - There are other 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. TTL on rows --- Key: CASSANDRA-2469 URL: https://issues.apache.org/jira/browse/CASSANDRA-2469 Project: Cassandra Issue Type: New Feature Components: Tools Affects Versions: 0.7.4 Reporter: Patrick Julien Priority: Minor It's currently possible to achieve this by setting a TTL on every column found in the row. However, in some scenarios, that requires too much storage. A TTL on the row itself would be a more concise and space efficient way of doing this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7534) TTL on rows to ensure data consistency
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)
[jira] [Commented] (CASSANDRA-7534) TTL on rows to ensure data consistency
[ https://issues.apache.org/jira/browse/CASSANDRA-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058666#comment-14058666 ] Morten Jorgensen commented on CASSANDRA-7534: - Robert, thanks a lot for your comment. This explains the negative impact of doing what I am trying to do. Each access to a web session would require the TTL to be updated, regardless of if the actual session data changes or not. This again means that I do indeed hit the anti-pattern in Aleksey's article. I do _not_ want to store session data in memory in Tomcat, as this forces me to use a sticky load balancer. I want any request to be able to hit any Tomcat node, and let tomcat be completely stateless and horizontally scalable. If this means that I need to run periodical purge-scripts across my sessions in Cassandra then so be it. 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)
