Out of curiosity will it work fine with multiple users connecting
on the same
database at the same time? I'm not too much
concerned about the possible issue of having two users try to change the
same object, which should fail if transactions are used. (From
experience the two most likely source of issues would be long-running
transactions and local caching of data... if data is read every time and
change are committed instantly then it should work fine...)
Don't get your hopes up. Gramps was written as a single user
application. While we have what we call 'transactions', they are NOT
what a db person considers a transaction. Instead they are a grouping
of related commits managed together by the application. They support
undo/redo and the only thing we guarantee is that the db is consistent
before and after the transaction. It may not be consistent in the
middle (consistent meaning that various references to other objects
are correct).
In particular, I'm pretty sure that there is no 'locking' of the db
during the transaction, at any level. There was a long thread among
the developers a while back where potential mechanisms for that were
discussed, but as far as I know, nothing was coded.
So multiple users are certain to cause trouble if they ever work in
the same regions of the db. And there is a lot of 'local caching of
data' involved in the GUI and object editors. We depend on the
editors to manage the consistency, they DON'T 'read the data every
time and commit instantly', and if you look hard you can find cases
where this is not handled well between various GUI elements even now.
Thanks, although what you describe is a pretty safe behavior with regard
to the DB. Additional safety may be provided by changing the default
transaction isolation level (I'm just reading about PostgreSQL now... it
appears the default is Read Comitted while MySQL's default is Repeatable
Read) - see https://www.postgresql.org/docs/9.1/static/transaction-iso.html
If two transactions try to change the same rows one will be locked until
the other completes, and if a deadlock occurs (both tx waiting for each
others) one will be rolled back and the client will get an error. That
could happen, and in a perfect world gramps should check the the data
it's trying to change hasn't been modified by someone else and then
retry the transaction. I assume that will not be the case, but if each
edit is done as a single transaction then at the very least the possible
loss is limited to a single edit.
With the default isolation level of PostgreSQL I don't think this could
even happen unless two tx change the same rows in parallel (previously
read rows will not be taken into account), OTOH there will be no warning
if the same field gets changed consecutively by two users if one commits
before the other starts updating (the latter will blindly overwrite the
former).
The other issue can be caching. If Gramps doesn't read data from the
database every time then it is hard to see what others have done just
before you. In alpha-1 caching was not an issue, though you may have to
switch between objects to refresh data (there may be a need for a
refresh function...)
Oh, last but not least, I haven't yet checked if this was fixed in
alpha-2 (since MySQL support was dropped I need to setup PostgreSQL
instead...) but Gramps should attempt to reconnect if the connection
dies (if it happens during a transaction the tx should be assumed to
have been rolled back*)
(*) A configuration option in MySQL changed default setting a few years
back to rollback only the timeout statement, not full tx... In
PostgreSQL it appears it rolls back the the full tx which is the safe
behavior (based on user comments; I haven't yet found an explicit
statement about this in Postgres documentation). This is only for TCP
timeouts during a statement, not deadlocks/timeouts that leaves the
connection open. When in doubt the safe thing to do is to rollback and
try again.
Regards,
--
Thomas