After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 592358 - concurrent usage is not operating
concurrent usage is not operating
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: Backend - SQL
2.3.x
Other All
: Normal enhancement
: ---
Assigned To: Phil Longstaff
Chris Shoemaker
Depends on:
Blocks: 722121
 
 
Reported: 2009-08-19 17:35 UTC by David
Modified: 2018-06-29 22:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David 2009-08-19 17:35:49 UTC
Guys,
you decided to enable database back-end. Which is definitely the best decision you could ever do! Thanks to this, GnuCash will soar to a new levels. Its future is great.

So far, GnuCash uses the database storage in the very same mode as the xml files. I mean: multiple users can't access the accounts saved in database concurrently.

Current behavior:
when I connect to the datasource from one PC, I can use GnuCash normally.
When I connect to the same database from an other PC (while the first relation is stil open), I can list the chart of accounts, but can not read registries, can not see the individual transactions etc.
If the second users wants to access the data, the first user must close its session, and the second one must start his session then.


This is obviously a relict of the xml files approach. I can't imagine the extent of the work related with enabling concurrent usage of the accounts in database. But it is obviously its nature.

The main reason and the main purpose of porting the accounts to database is concurrent access by multiple users... There is no other persuasive reason to port from xml files to database.

Please, how is it with the roadmap to the concurrent usage of data in database?

Thank you much guys,
David
Comment 1 Phil Longstaff 2009-08-21 19:33:24 UTC
It was never designed for concurrent operation.  Enhancement.
Comment 2 David 2010-02-24 17:39:08 UTC
Now (in version 2.3.10), the behaviour is much better than described above:

I can connect to the datasource from one PC and I connect to the same database from an other PC (while the first relation is stil open). I can work normally in both the sessions concurrently.

There is one limitation:
When session A writes something, session B does not see that until reopening the database (reconnecting). And vice versa.

So, no transaction is lost, but the other users can not see them until reopening(reconnecting). Refresh does not help to solve that.

In my opinion, you could support concurrent usage VERY EASILY:

- Add "concurent usage" option
- "Refresh" button would reopen/reconnect (when this is a database connection and when the "concurrent usage" option is on)

This is probalby a quick and dirty solution since reopening all the tables takes time. But better than nothing.


More clean solution would be to refresh just the active dataset (the account I have open).
Comment 3 John Ralls 2018-06-29 22:26:50 UTC
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=592358. Please continue processing the bug there and please update any external references or bookmarks.