Consider making SwingStore Exporter DB connection Read-Only

[siarhei-agoric]

What is the Problem Being Solved?

Currently, exporter.js:100 uses RW DB connection and relies on a read transaction to guard against any potential DB modifications:

  const filePath = dbFileInDirectory(dirPath);
  const db = sqlite3(filePath);

  // Execute the data export in a (read) transaction, to ensure that we are
  // capturing the state of the database at a single point in time. Our close()
  // will ROLLBACK the txn just in case some bug tried to change the DB.
  const sqlBeginTransaction = db.prepare('BEGIN TRANSACTION');
  sqlBeginTransaction.run();

We might get a bit better non-modification guarantees if exporter requests an RO DB connection explicitly.

Description of the Design

Pass options.readonly as an options argument to sqlite3() to request an RO connection.

Things to keep in mind:

• a read-only connection does not imply a read-only database and read-only database does not mean that the actual DB file and its parent directory are read-only.
• an RO connection still writes to WAL in order to properly manage read transaction concurrently with any other DB users.
• there are lots of CREATE IF NOT EXISTS in downstream APIs used by the exporter (ex: transcriptStore.js:105)
• need to confirm and ensure no exclusive DB connections are used anywhere else in the code.
• read transaction is still required to acquire a coherent point-in-time view of the database.

Security Considerations

An explicit read-only connection from exporter would be an improvement from security standpoint.

Scaling Considerations

Explicit RO connection could potentially improve DB performance during concurrent access as the DB engine can make certain assumptions about the nature of the access based on the connection type.

Test Plan

Need to make sure exporter-specific RO connection has no impact on kernel's RW connection while used concurrently.

Upgrade Considerations

This should not impact an upgrade strategy.