[
https://issues.apache.org/jira/browse/CASSANDRA-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058657#comment-14058657
]
Robert Stupp commented on CASSANDRA-7534:
-----------------------------------------
I guess what you want (in CQL terms) is "TTL on partition key" - am I right?
IMO the problem with your particular use case is that the TTL changes whenever
a session is used (no implicit change of session data). Means: you need to
change the TTL of the whole partition although the data has not changed ("user
is just browsing on the site"). This implies a lot of writes without changing
data - and each write "invalidates" older writes for the same session. If i'm
right, then you get into a similar problem that [~iamaleksey] described here:
http://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets
It's perfectly valid to store servlet API session data in C* - but you have to
do it "right". This does not only mean to create a proper data and access
models but also to route the same HTTP session to the same web server (in this
case Tomcat) to keep session data local within the same JVM and not just
multiplying access load from Tomcat to C* (which may have to replicate your
session data). Means (for this use case) just use C* as a storage to failover a
HTTP session to another Tomcat. And only update the partition TTL (by
re-inserting all current data) at very low frequency.
But despite your use case, I think there is already another JIRA ticket that
covers the same ("update TTL on row") or similar scenario - not sure.
> 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)
