[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] SQLite3 bindings for CHICKEN 4

From: Thomas Chust
Subject: Re: [Chicken-users] SQLite3 bindings for CHICKEN 4
Date: Wed, 12 Aug 2009 12:07:55 +0200

2009/8/12 Jim Ursetto <address@hidden>:
> On Wed, Aug 5, 2009 at 9:02 AM, Thomas Chust<address@hidden> wrote:
>> If, for example, you prepare a statement and forget to ever execute
>> and finalize it, my sqlite3 egg will at least tell you that you have
>> an unused statement lying around when you try to close the database.
> sqlite3 will tell you with an error, and then permanently prevent you
> from closing the database.  If that statement was executing
> and you don't have a pointer to it, you've probably wedged the
> database, and must abort your process.
> [...]


when I first wrote my SQLite3 bindings, it was not easily possible to
prevent that problem without using a statement cache, which I didn't
want to do, and I decided it was, although annoying at times, not big
enough a problem to worry about very much.

The situation is similar to file I/O operations: If you don't want to
see errors when closing the file descriptors, just terminate the
process instead and everything will be cleaned up as well. This also
works flawlessly with SQLite3 databases.

Since recent versions of SQLite3 contain facilities to iterate over
all prepared statements associated with a database, I could actually
make the finalize! routine of my SQLite3 egg clean up remaining
statements as well when closing a database. I think I will make that
change and also move to the sqlite3_prepare_v2 API for preparing
statements, which is less error prone. But I still think an error
should be raised by finalize! when orphaned statements are found.

> [...]
>> Opening multiple database connections to the same database
>> from inside the same operating system thread, like sql-de-lite
>> claims it is possible, only helps if you are lucky either, since
>> it may cause locking problems.
> Locking problems which the interface is designed to avoid.

Hmm, I'll have to take a closer look at the code, but I think it is
technically impossible to prevent all the locking problems I can
imagine here, because the locking facilities employed by SQLite3 at
the operating system level just don't have a finer granularity than
operating system threads.

> [...]
> And, even if you do use one connection for multiple
> threads, other processes can still be locked out of the
> database indefinitely in case of programming error.
> [...]

This is not a valid argument in my eyes. Anything can happen in case
of programming error. A database lockout can, for example, easily
happen when an exclusive transaction is not terminated and the process
keeps running.

> [...]
> I think it is useful to have two eggs with different design approaches.
> Both have their strengths and weaknesses.
> [...]

Yes, having a choice is usually not bad :-)


When C++ is your hammer, every problem looks like your thumb.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]