Forum Discussion
Hi Piotr,
using a (random?) "cookie value" as "subtable_name" would be a good choice to distribute the RAM consumption across your TMMs evenly. Each cookie value will get its own subtable and each single subtable would be randomly pinnend to a different TMM.
But I still dont get the point how you're trying to access and enumerate a specific subtable without knowing its name in advanced? I'm asking because you simply can't enumerate subtable names using the table command. You are just able to enumerate every contained "subtable key" of a given "subtable name", but the "subtable name" MUST be somehow known (a fixed value or provided by the client).
But you may want to store every "subtable_name" (aka. your cookie values) in an seperated and known "subtable_name_subtable" (aka. a subtable containing every cookie value as a key). By doing this, it will be possible to enumerate the currently strored subtable_name's and access the data of every single key of those tables.
If using a single "subtable_name_subtable" the RAM consumption may become distributed uneven again. Using multiple well-known "subtable_name_subtables" (e.g. a dedicated subtable for every first letter/didgit of the cookie value) the ressource consumption of the contained data could be distributed across multiple TMMs again.
BTW1: There is no option to query the creation or last accessed time. Either store/update a timestamp when created/accessed or do some math based on the -remaining values.
BTW2: Using indefinite key lifetimes could be a dangerous task, if the creation of the keys can be triggered by end-users without restricting the maximum number of tables/keys. It may exhaust to much of your TMM memory without releasing it and therefor requires a manual garbage collection.
Cheers, Kai