Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re: Re: Caching DBM hash tie

by Tardis (Pilgrim)
on Jul 16, 2003 at 01:12 UTC ( [id://274650]=note: print w/replies, xml ) Need Help??


in reply to Re: Caching DBM hash tie
in thread Caching DBM hash tie

It's actually not really that much of a bandaid, when you think about it.

It's a general purpose extension to a simple tie that provides SQL-like concurrency to a standard hash mechanism.

For what it's worth, the code to convert the app to a half-baked SQL solution is actually written. There is just a fairly high scare factor in actually using it.

Current code uses the ability to lock the entire database as a way of ensuring data integrity (say during financial operations). That needs to still happen, but if we left all the locks in as they were we'd gain no benefit from having SQL.

The solution was to use PostgreSQL's SELECT ... FOR UPDATE in appropriate places, along with SET TRANSACTION SERIALIZABLE to lock rows we are about to (or may be about to) change.

All of these things mean API changes and possibly data integrity issues if not done correctly.

Breaking the API as little as possible is a real issue here.

Replies are listed 'Best First'.
Re: Re: Re: Caching DBM hash tie
by waswas-fng (Curate) on Jul 16, 2003 at 01:22 UTC
    You may be able to get some performace boost with MLDBM::Sync it allows you to batch lock and cache. But any row level locking you try to acomplish still has the same problems you describe above...

    -Waswas

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://274650]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others wandering the Monastery: (1)
As of 2024-04-25 04:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found