The table Command: Advanced 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 fifth part of the series on the usage of the new table command, we discuss advanced concepts around data lifetime and expiration from the session table.

Advanced Data Expiration

On the off chance that your iRule does need to keep close track of varying timeout or lifetime values, then you should know some important ways that they might or might not be changed.

As you might expect, all of the other subcommands to set values take the timeout and lifetime parameters as well:

table set [-excl|-mustexist] <key> <value> [<timeout> [<lifetime>]]
table add <key> <value> [<timeout> [<lifetime>]]
table replace <key> <value> [<timeout> [<lifetime>]]

However, the add and replace subcommands are designed to sometimes not update the data. For example, if you call table add with a key that already exists, then the data will not get updated. In all cases, if the table command doesn't update the data, then it doesn't update the timeout and lifetime either. If it does update the data, then it does update the timeout and lifetime.

So, if you have a table that looks like:

and you run:

table set 10.1.2.3 UserQuux indefinite 3600

then you end up with:

The timeout and lifetime both got updated because the data was updated. If you then ran:

table add 10.1.2.3 UserBar 120 120

then the table would not change at all. Because the data did not get updated, the timeout and lifetime also didn't.

Sometimes you might want to update the value and not touch the existing timeout or lifetime values, even though you don't know what they are. By specifying a 0 for either the timeout or the lifetime, or by omitting the lifetime, that parameter is not changed even if the value is updated. So if you had the previous table and then ran:

table replace 10.2.9.12 UserZap 180 0

you would get:

You can see that the entry's value and the timeout were changed, but the lifetime was not.

 Continue reading part six in the series: Subtables