QOF-to-SQL Proof of Concept

[Derek Atkins]

Benjamin Carlyle <benjamincarlyle at optusnet.com.au> writes:

> 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.

Good.  This is exactly what I expected.  So long as this works across
multiple applications connecting to the same database, then it's just
fine.  I think we'll still need to do some sort of internal locking
to stop the race condition of having two apps trying to change the
same piece of data..

I guess we could have the internal "begin edit" actually perform a
database lock, but that's not really a viable option because the app
could hold that lock for a long time waiting on user input.
So we just need to be careful to:

lock db
do {
   check status
   if (status changed)
      break;
   update record
} while (0);
unlock db

I'm not sure a BEGIN TRANSACTION / COMMIT TRANSACTION is sufficient to
do this, unless we can actually perform a SELECT and get back real
data in the middle of a transaction?

> Benjamin.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available