While in TDB2, read-transactions never write, there is a case where a
read-only setup needs to do writes.
It happens only at start-up and only the first time after the database
is written during setup.
If there is a journal file with outstanding changes, these are completed
before the database is passed to the application. It means there was an
abnormal termination during the last write transaction after the commit
point. The timing window for that is quite small.
A simple way is to prepare a database is to do a query on it as a
separate process after it's been written : e.g.
tdb2.tdbquery --loc DATABASE 'ASK{}'
TDB1 is different; read-transactions can do some completion actions. The
journal is more heavily used.
Andy
On 18/09/2023 16:35, Jim Balhoff wrote:
On Sep 18, 2023, at 11:09 AM, Andy Seaborne <[email protected]> wrote:
On 18/09/2023 15:35, Jim Balhoff wrote:
Thanks, I think that’s basically what I’ve got. The only operation I have
enabled is 'fuseki:query’. But Fuseki still complains if the filesystem is
read-only.
The database is opened before the configuration is processed.
Also, there is only one "database" java object for each database location and
something elsewhere may now or later open it for other operations.
This could be changed - file management is (should be!) centralized in the
codebase.
Got it, thanks. It isn’t too big of a problem; it would just be convenient for
some situations like scaling up multiple servers in Kubernetes.
