The table Command: Data Expiration

With version 10.1, we've given the session table some long-sought functionality, and revamped its iRules interface completely to give users a new, cleaner, full-featured way to keep track of global data. We are very proud to introduce the table command...

  1. Basics
  2. New Ways To Set Data
  3. New Ways To Alter Data
  4. Data Expiration
  5. Advanced Data Expiration
  6. Subtables
  7. Counting
  8. The Fine Print
  9. Examples

In this fourth part of the series on the usage of the new table command, we discuss data lifetime and expiration from the session table.

Data expiration

Remember that I mentioned that an entry also has metadata? Prior to v10.1, the only metadata that an entry had was a timestamp, which keeps track of when that entry was last touched (changed or queried), and a timeout. The touch timestamp can’t be directly set by iRules, of course. It’s used internally by the session table to keep track of when to expire entries. So a small session table might have looked like this:

You can see a number of different types of keys and values, each one with a timeout and a timestamp. One common request to enhance the session table has been to have some way of looking up an entry without affecting the touch timestamp, so we added the -notouch flag to the table command:

table set [-notouch] $key $data
table lookup [-notouch] $key

With this flag, you can query the session table without changing when the entries will expire. But we felt that that didn't go far enough for some uses, so while the session table looks much the same in v10.1, it has two additions:

Just as before, an entry has a touch timestamp and can have a timeout, but now it also has a create timestamp (to record when the entry was created), and it can also have a lifetime. By setting a lifetime on an entry, you can have it expire after a certain period of time no matter how many changes or lookups are performed on it. An entry can have a lifetime and a timeout at the same time. It will expire (be removed from the table) whenever the timeout OR the lifetime expires, whichever comes first. You can just specify the lifetime right after the timeout value:

table set <key> <value> [<timeout> [<lifetime>]]

If you want an entry to only have a lifetime, and not a timeout, you can specify an indefinite timeout. For example:

table set $key $data indefinite 3600

will set an entry that will be removed after 3600 seconds. By default, an entry has a timeout of 180 seconds (just like previous versions), and an indefinite lifetime.

For most uses of the session table, the user will specify timeout and lifetime values when an entry gets set, and never explicitly worry about them afterwards. If you do need to query or change those values on an entry, then you can do so directly:

table timeout [-remaining] $key
table timeout $key <value>
table lifetime [-remaining] $key
table lifetime $key <value>

These commands operate exactly as they read: you can query or set the lifetime or timeout parameter which the entry has, or you can query the remaining time that an entry has left. Note that these commands never affect the expiration of a record. In other words, they always implicitly have the -notouch flag set.

 Continue reading part five in the series: Advanced Data Expiration

Published Jan 13, 2010
Version 1.0

Was this article helpful?

No CommentsBe the first to comment