Re: BDB corrupt
- From: "Kurt J. Lidl" <lidl@xxxxxxx>
- Date: Tue, 13 May 2008 11:48:41 -0400
On Tue, May 13, 2008 at 03:44:06PM +0400, Anthony Pankov wrote:
My requirements is
1. there is no need for SQL
2. processes are sharing db file in concurrent mode
3. reading/writing = 60%/40%
clause 1 - satisfied
clause 3 - satisfied (databases of relatively small items that are
Is there a problem with concurrent access? And, most important, is
this the ONLY problem? (I still don't understand because of blurred
mention of "data corruption".)
If concurrency is the only problem then:
1. Can data corruption be avoided? Or this is impossible?
If all BDB readers would use O_SHLOCK and all writers O_EXLOCK is it
guarantee for data integrity?
This is probably good enough, if your writers also do a fflush()
before releasing the lock. If the writing process ever dies
horribly, you can still have database corruption.
You could turn the thing that does the actual I/O into the database
into daemon that fullfils read/write requests from a unix domain socket.
In fact, there is a sample application that does exactly that for
the newer Sleepycat BDB code. It could probably be adapted or
re-written for the 1.8x series code.
If it were me, I'd just punt on using the 1.8x code, drop straight into
using the BDB 4.6 codebase, and use their transactioning code. It's
mature, robust, etc, etc, for a much large set of operations than
the 1.8x code ever was. But there's still that licensing issue.
freebsd-hackers@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"
- Prev by Date: Re: BDB corrupt
- Next by Date: Re: BDB corrupt
- Previous by thread: Re: BDB corrupt
- Next by thread: Re: BDB corrupt