Hey, I just committed version 0.3 of ObRegistry, complete with a BVT for basic functionality. The next script I'll need to write will test contention handling. This new one is completely re-thought and re-written, I can't even say refactored. The only thing in common with the old one is the concept of storing objects on disk. I can get away with doing it from scratch, because it's still in an alpha-type phase (v < 0.5)...
[insert: damn you blogger! you ate a bunch of text becaue I typed a less-than sign ... rackin' frackin' piece o' ... rrrggghh!]
... name of an object to load or create, you indicate key properties when creating an instance of ObRegistry. Objects are then stored in a path hierachy matching those key properties. Locking is achieved by creating, and holding onto the handle of, a zero-byte file in the ",locks" directory. I use commas to delimit special things, because object file names are URL-encoded and thus will never contain commas. Lock file names are generated using a 32-bit hash function I borrowed from Paul Hsieh (I had to convert it from C to JS of course).
Locking and releasing occurs automatically within the Save/Create/Delete functions, but can be done explicitely to block other processes during any part or the entire lifetime of an object. For example, you might Lock several objects before making your modifications and then Release them all when you are finished: transaction-like. All locks are released when the ObRegistry Close function is called.
Actual transaction capabilities like rolling-back was removed due to the complexity it added to script, I had no tests to even prove it worked, and its necessity was unlikely due to it only helping in instances where FSO's Write() failed part-way through; that generally won't happen, rather Windows' will spew "Delayed Write" errors. Also, simply the ability to roll-back a single file doesn't really constitute transactions. I've tried to make this version as atomic as possible, with things occuring as you tell it to do them, rather than "automatic" things happening.
Ah, and the requirements are so much lower. You can throw this beauty into an ASP, scheduled task, HTA, whatever. It doesn't require a second task to do clean up and it only requires one other module (cereal.js).
Next ... I'll use it for something besides secret day-job projects!!