Benjamin Carlyle <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
