I am not certain how big Sleepycat's release is any more, but
I think a DB::Inline done with Inline.pm wrapping sleepycat code
would be an interesting project. That might just move the problem
from library synchronization to making sure that everyone has access
to a compiler though.
I would like to hear more about the "record level locking and
transactions." Perltie does not support these features: what will
the interface look like? My own efforts to do record level locking
with DirDB from above the perltie are done by:
reserve a record key for held lock id (such as "LOCKEDBY")
create a thread-unique identifier ("TUI")
WAIT:
wait until LOCKEDBY is undefined or set to a reserved "NOONE"
value (and not stale -- staleness is a severe problem)
write the TUI to the held lock field
wait as long as it might take a different thread to write
its TUI (implementation-dependent)
read the held lock field, if it does not match what I just
wrote there return to WAIT
now I have exclusive access to the record so I can increment
or decrement the transaction-safe field
set the held lock field back to NOONE (or delete it)
but some of the details could very well be done with additional methods,
such as
tied(%Record) -> Set_Exclusive_Lock();
$Record{BALANCE} += $fee;
tied(%Record) -> Clear_Lock();
Are there other TIEHASH modules that implement such things, and what
names do they use? When you are the first to add a feature like this,
I think it is a good idea to try to name the methods by function so that
other implementations of the same semantic can reuse your interface.
If you're making up your own file format, how about CorlissDB?
You said "support tied hashes" -- Did you mean support for storing
hash references?
I added support for hash references to my DirDB (and DirDB::FTP)
modules and would appreciate your feedback on the semantics of the
interface. They are as follows:
When you store a reference to a native perl hash to DirDB,
the hash becomes blessed so that further manipulation of the referenced
hash manipulates the persistent store as well.
When you store a reference to a tied hash to DirDB, you get
a deep copy.
When you store anything other than a scalar or an unblessed hash
reference, the module throws a croak without overwriting or corrupting
These semantics make it possible to do multi-level autovivification
inside a DirDB data structure, even over the network (by FTP.)
On Fri, 2004-01-02 at 12:48, Arthur Corliss wrote:
> [...] Modules like
> AnyDBM_File and DB_File are causing some unpredictable results in some of my
> code, depending on the version and implementation of the dbm libs they're
> linked against. This is just my way of getting predictable results without
> requiring admins to upgrade or install new system libs, along with the
> requisite Perl modules.
>
> --Arthur Corliss
> Bolverk's Lair -- http://arthur.corlissfamily.org/
> Digital Mages -- http://www.digitalmages.com/
> "Live Free or Die, the Only Way to Live" -- NH State Motto
--
david nicol
And now for something boldly anticlimactic.
