QOF-to-SQL Proof of Concept

[Benjamin Carlyle]

On Sun, 2004-05-30 at 00:30, Derek Atkins wrote:
> I'm envisioning multiple gnucash applications "opening" the same
> database and then each app reading/writing as necessary for its
> operation.  Obviously the writes need to be serialized (you can't have
> both apps "writing" at the same time, but my hope is that the locking
> semantics are such that when app1 tries to perform an UPDATE, it will
> lock out app2; when the update finishes the lock is released and then
> app2 can perform its UPDATE.

> I don't care that this lock is on the whole database, just so long as
> the database handles it for me, and that I don't need to specifically
> say "I'm opening the database for writing".

The database handles it for you.

Whenever you say "BEGIN TRANSACTION;" a exclusive lock will be placed on
the whole database. When you commit or rollback your transaction the
lock is removed. Any insert, update, or other operation that modifies
the database will implicitly begin and commit a transaction during its
execution. Every select statement locks the whole database with a shared
lock and unlocks when the query is done.

Benjamin.