Would this perhaps affect throughput in the case where multiple database
files are open?  For example, I have a handful of databases (10?) that are
open at any given time, and reads and writes are taking place on separate
threads.  Naturally writes that happen to the same database ultimately get
serialized by the database-level locks, but writes to other databases
continue to work.  But using the async feature would serialize all reads and
writes to all databases, is that correct?

Thanks
Doug

> -----Original Message-----
> From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
> boun...@sqlite.org] On Behalf Of Christian Smith
> Sent: Friday, May 08, 2009 7:24 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] SQLite version 3.6.14
> 
> On Fri, May 08, 2009 at 05:32:45PM +0700, Dan wrote:
> >
> > On May 8, 2009, at 5:21 PM, Christian Smith wrote:
> >
> > > On Wed, May 06, 2009 at 10:36:50PM -0400, D. Richard Hipp wrote:
> > >>
> > >> A new optional extension is included that implements an
> > >> asynchronous I/
> > >> O backend for SQLite on either windows or unix.  The asynchronous
> I/O
> > >> backend processes all writes using a background thread.  This
> gives
> > >> the appearance of faster response time at the cost of durability
> and
> > >> additional memory usage.  See http://www.sqlite.org/asyncvfs.html
> for
> > >> additional information.
> > >
> > >
> > > What are the benefits of using async I/O over "PRAGMA synchronous =
> > > OFF"?
> > > If AIO is used for the rollback journal as well, you've lost your
> ACID
> > > properties already, so you may as well just use "PRAGMA synchronous
> > > =  OFF"
> > > anyway and keep the code simpler.
> >
> > That's not the case. You lose the Durability property, in that a
> COMMIT
> > statement may return before a transaction is stored on the persistent
> > media,
> > but transactions are still Atomic, Consistent and Isolated.
> >
> > When using the "PRAGMA synchronous=off" your database might be
> corrupted
> > by a power failure or OS crash. When using asynchronous IO this
> should
> > not
> > be possible (assuming the hardware is not being untruthful - just as
> > when
> > using regular "PRAGMA synchronous=full" mode without the async IO
> VFS).
> 
> 
> Ah, the bulb has lit. Because the writes and syncs are processed by the
> single queue in order, journal writes are guaranteed to be synced and
> consistent before main in-place updates to the db file.
> 
> Might be worth mentioning this in the documentation, as this is not
> clear without examining the source.
> 
> In that case, I like it :)
> 
> Is this something that might be made the default in the future, with
> the
> addition of some synchronization between foreground and background
> threads
> on the xSync messages to emulate the existing "PRAGMA synchronous=full"
> behaviour?
> 
> >
> > Dan.
> 
> Christian
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to