TTL to expire items at the end of their lease

[mihilmy]

Java version of the distributed locks proposed using server side TTLs to keep the table size small. For example, if your application will write on ingestion of an item but then is predominantly doing reads. It does not make sense to keep that item in the table. Would you folks be open to me submitting a PR for that?

Reference: https://aws.amazon.com/blogs/database/building-distributed-locks-with-the-dynamodb-lock-client/

[tristanls]

DynamoDB server-side TTL feature requires that an attribute be present that is a number timestamp in Unix epoch time format in seconds, for example 1645119622, that is Thursday, February 17, 2022 17:40:22 (GMT). Then the DynamoDB table can be configured with a TTL using that attribute name.

You cannot use the above feature to expire items at the end of their lease. You can use the feature to expire things on the scale of days. "TTL typically deletes expired items within 48 hours of expiration".

If the desire is to automatically DynamoDB clean up old data after a few days, then adding number timestamp in Unix epoch time format in seconds field seems to be the thing to do. We already do something like that with lockAcquiredTimeUnixMs, but that's currently conditional and in milliseconds. I'm guessing the work here would be to add lockAcquiredTimeUnixSeconds attribute for all fail open lock data entries which would allow someone to configure DynamoDB table TTL out-of-band.

[mihilmy]

Thank you for getting back to me so quickly. Yes I should have clarified the intent. It's exactly as you pointed out. The one flexible approach I would give is to allow users to specify a field name that would be used for TTL instead of hardcoding to lockAcquiredTimeUnixSeconds that could be passed in the client config. Should I convert this into a feature and submit a PR?

[tristanls]

Sounds good 👍