mirror of
https://github.com/Gnucash/gnucash.git
synced 2026-10-25 23:50:06 -05:00
Noah R
5dc53303b5
qof_session_end() is documented to release the session lock and shut the
backend connection but it does not release the session lock in all scenarios
(BUG). qof_session_end() looked the backend up via qof_book_get_backend().
The book's backend pointer is only set by load() or a data-changing save() (an
empty book's save() early-returns before attaching it); begin() sets only the
session's own m_backend. So a session that creates a store and ends it without
loading or making a real change had a backend on the session but not on the
book: end() found none, skipped session_end(), and never released the lock --
it was only released later at destroy().
Because the fault is in backend-agnostic engine code it affects every backend
that locks at begin(): the SQL/DBI backends leave a stale row in the gnclock
table, and the XML/file backend leaves an abandoned <file>.LCK sentinel (with
no data file, since XML data is only written at save). The store then appears
locked to the next opener.
End the session's own backend (m_backend, always set at begin()) instead. It
already equals the book's backend whenever the latter is set, so the change is
a no-op for loaded/saved sessions and additionally covers the
created-but-not-attached case.
Add regression tests for both backends, each of which begins a create-mode
session, ends it without a data-changing save, and checks the lock is gone:
- test-backend-dbi-basic.cpp (test_dbi_new_store_end_releases_lock): reopens
the store and asserts it is not ERR_BACKEND_LOCKED.
- test-load-backend.cpp (test_new_store_end_releases_lock): asserts the XML
<file>.LCK lockfile has been removed.