Need clarification/documention about JobStorageTransaction (AddRangeToSet, AddToSet, InsertToList, IncrementCounter)

[robin-83]

Hi,

I would like to know, if I can use e.g. JobStorageTransaction.AddToSet to persist custom data in the Hangfire database. If so, is there a best practice how to name the keys, so that name conflicts are avoided?

My use case: I am using Hangfire to automate a third party application, which needs to be restarted after a certain amount of times the app has been automated by my Hangfire job (not a Timespan). So I have to keep track of the usage for this machine only (multiple Servers exist).

I am planning to use IncrementCount (only if I can reset or delete it) or a simple key value entry:
Key="custom:ThirdPartyAppUsageCount{machinename}", value=counter

May I use the built-in Hangfire tables for this or do I need to persist this in an additional data source?

Robin

[odinserj]

Yes, you can surely use all of the available methods. As for the uniqueness, you are correct, it's a difficult question, and unfortunately there are no general guidelines here. So a good prefix, may be including your application or solution name, is essential. I'd also recommend to use alphanumeric characters with the reasonable set of punctuation, and avoid using complex unicode characters there.

[robin-83]

Nice, I will definitely give that a try!

I am currently investigating the Api and I do not see a way to reset a counter to zero or delete it entirely. Is there a public method available?

[meiranzheng]

You can use the storage primitives (IWriteOnlyTransaction) for custom data — they’re part of Hangfire’s public storage API and are commonly used by extensions — but I’d still treat Hangfire storage as “infrastructure data” rather than a general-purpose app database.

If you do store custom data there:

• Use a unique prefix/namespace for keys (e.g. myapp:...), and keep key cardinality bounded.
• Consider AcquireDistributedLock(...) if multiple workers/servers might update the same key concurrently.
• Prefer data structures you can manage lifecycle for. For example:
  • IncrementCounter(key, expireIn) supports expiration, but there is no direct “remove counter” API in IWriteOnlyTransaction.
  • A Hash (SetRangeInHash / GetAllEntriesFromHash / RemoveHash) is often easier if you need to reset/delete.

For your per-machine usage counter, a hash like custom:ThirdPartyAppUsageCount with a field per machine (or serverId) can work well, and you can reset by setting the field back to 0 or deleting the whole hash.

If this counter is truly application state (not tied to job processing), a separate data source/table is still the safest long-term option.