Re: [Gramps-devel] Application level locking

[Nick H. <ni...@gr...>]

On 13/02/17 23:48, John Ralls wrote:
> That requires you to get closer to the iron than you want, because you have to ensure that exactly one module handles all access to the lock table and that that module is protected by a mutex. Even that will fail in multi-user access because each instance of Gramps will have its own mutex. Besides, locking alone isn't sufficient. You also want transaction support so that in the census editor case either both the census*and*  the person records get saved or neither gets saved, and you want foreign key constraints to prevent dangling references between the two; that applies to the event-deletion case you led off with as well.
>
> BDB and SQL provide facilities (locking, transactions, and foreign key constraints) that handle these problems safely and with much less work. Use them!
>
> Note that different database engines do locking differently. For example in BDB you can lock individual rows; in SQLite3 the lock is on the whole database, while MySQL and PostgreSQL explicitly lock tables (they'll lock rows during queries, but you don't have enough control over that process to protect every case).
>
> In the case of the census editor you also want a transaction that wraps both insert operations to make the whole thing atomic so that if writing the person.

We already wrap all the save operations in a transaction.

The problem is more at the application rather than database level. When 
we invoke an editor we make a copy of the object.  When the "OK" button 
is clicked we save this copy along with any changes made.

I don't think that extending transactions to cover the lifetime of an 
editor would do what we want.  A more usual solution would be to modify 
the editors to that they only update fields that are changed, but that 
is not easy.


> For the earlier case of deleting the event out from under the person, it could be addressed with locking but foreign key constraints will work better and more generally.

At present, there are no foreign key constraints on our tables. The 
reference fields are hidden within blobs.


Nick.