mitd has asked for the wisdom of the Perl Monks concerning the following question:

After several months of cleaning up a J2EE mess (hey 7 kids and folks in trouble (as long as you are not the cause) always pay well and up front) I am delighted to be back solving interesting problems with Perl.

We are presently doing some clever Perly to get two legacy financial services systems to talk to each other and exchange data, ideas and wives.

As is quite common with these pass the transactions thingies I find myself preparing to write a persistent sequential counter ('Holy Spider Pucks' did I just describe a Web counter NOT!) for the purpose of supplying unique request ids to be included in XML formatted requests.

Stop! I am not about to ask for code! Carry-on

There are some constraints: an RDBMS cannot be used. (MySql auto-increment would be lovely but not an option). There is a need to group some ids Ala one side of transaction generates ONE REQUEST but the when it reaches the other side it has has broken into 3 sub requests that each require there own id eg ReqID 100 becomes subReq 100A, 100B, 100C.

So there it is simple really I know. So flat file it with locking, maybe use Storable, tieScalar to persistent store or how 'bout storing right in script Ala Damian's Inline::Files?

Just curious about some 'best thought' from the community collective or just ignore me and I'll go back to using my fingers and toes.

mitd-Made in the Dark
'My favourite colour appears to be grey.'

  • Comment on Persistent sequential transaction id generator

Replies are listed 'Best First'.
Re: Persisten sequential transaction id generator
by mattr (Curate) on Aug 02, 2001 at 12:34 UTC
    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.

[reply]
Re: Persistent sequential transaction id generator
by trantor (Chaplain) on Aug 02, 2001 at 16:53 UTC

    I wouldn't store it right in the script for these reasons at least:

    • One day you may need the counter in some other programs, and accessing it could be harder than it needs to be
    • There are several good reasons for not altering production scripts. Think about the consequencies of restoring the script from an old backup for example, the counter would be restored to an old, incosistent value
    • It makes debugging and testing unnecessarily complicated: unless you take precautions (e.g. a production counter and a test counter on different sections after the end of the script)
    • You may not have write permissions on the script at all, which is probably going to be the case, or the script itself might be on a read-only partition (quite an interesting security measure, especially when we're talking about finance and transactional computing)

    The most reasonable choice is probably following the KISS (Keep It Simple, Stupid) principle, storing the counter in a plaintext (easy debugging, no libraries required) file where locking prevents messy race contitions or nasty inconsistencies. Naturally the file name shouldn't be hardcoded in the source.

    -- TMTOWTDI

[reply]
Re: Persisten sequential transaction id generator
by merlyn (Sage) on Aug 03, 2001 at 02:41 UTC
[reply]

Back to Seekers of Perl Wisdom