Date: Wed, 14 May 2008 10:40:25 -0700 From: George Hartzell <hartzell@alerce.com> To: "Kurt J. Lidl" <lidl@pix.net> Cc: Garrett Cooper <yanefbsd@gmail.com>, Jeremy Chadwick <koitsu@freebsd.org>, Anthony Pankov <ap00@mail.ru>, James Mansion <james@mansionfamily.plus.com>, freebsd-hackers@freebsd.org Subject: Re: BDB corrupt Message-ID: <18475.9225.878567.877705@almost.alerce.com> In-Reply-To: <20080514135051.GA21370@pix.net> References: <9FC19AC2-DAD8-418C-8B9C-F129DEC58CEF@gmail.com> <15336578.20080512123806@mail.ru> <200805121153.00809.jonathan%2Bfreebsd-hackers@hst.org.za> <1663320218.20080512223531@mail.ru> <20080512152430.3720683e@mbook.local> <2117635718.20080513154406@mail.ru> <20080513121452.GA70860@eos.sc1.parodius.com> <20080513154137.GA28842@pix.net> <482A02CD.7040308@mansionfamily.plus.com> <D10ACB9D-8D1D-4696-BF7E-DBB0E9D74262@gmail.com> <20080514135051.GA21370@pix.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Kurt J. Lidl writes: > On Wed, May 14, 2008 at 12:25:16AM -0700, Garrett Cooper wrote: > > Most of the complaints about other DBs is licensing related, but SQLite's > > complaint was also the fact that the past stability record was a bit rocky. > > One other thing to watch for in SQLite is the lack of atomicity > in updates. It's not ACID, just like BDB 1.8x isn't ACID. > > Without a write-ahead log, you cannot be sure that the data written > actually made it to stable storage, and as such, you cannot be sure > that your database didn't get corrupted when the process stops in a > non-optimal way. In what way is SQLite not atomic? The documentation, Atomic Commit In SQLite, suggests that it is: http://www.sqlite.org/atomiccommit.html I don't know that it supports fully ACID (atomic, consist, isolated, durable) transactions or how it handles the various SQL standard transaction isolation levels (Read Uncommitted, Read Committed, Repeatable Read, Serializable) but I believe that updates are atomic and that it does as well as any db (in the face of lying synch. operations, etc...) to handle "non-optimal" stops. g.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18475.9225.878567.877705>