in reply to Persistent sequential transaction id generator

It seems to me that you could increase the robustness of the system if your program could take responsibility for keeping track of recent transactions and the processing involved to ensure multiple asynchronous requests and the related subrequest processing is handled correctly.

How about using a BerkelyDB to store those transactions in a btree (or something simpler if you use integer keys) and use some more tablespace for a scratchpad?

BerkelyDB is not an RDBMS but is a fast, powerful, persistent store. Mysql happens to use it too. It can save you from file open/close and synchronization problems too. Your program could run as a daemon or possibly even a called on demand program which saves its state in that scratchpad. You could schedule it to wake up periodically for sanity checks.

it may be more than you need but you also might consider Alzabo::ObjectCache::Sync::BerkeleyDB. This synchronizes multiple processes' use of a single object store and can also use a file instead of a BerkeleyDB.

  • Comment on Re: Persisten sequential transaction id generator