Storm could usefully support readonly Stores

Bug #137116 reported by Richard Boulton on 2007-09-03
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Storm
Undecided
Unassigned

Bug Description

In a mutithreaded environment using SQLite, it can be useful to have a policy that only one Store at a time may ever be written to, to avoid getting "deadlocks" (which are eventually resolved by a timeout leading to a "database is locked" exception).

When implementing such a policy, it would be useful to be able to mark any store which isn't intended to be written to as readonly, to avoid coding errors. Such a store would raise an exception (probably a ProgrammingError) whenever an attempt to change the data in the database was made (eg, by adding a document, changing a property in an object retrieved from the database, or by executing some SQL which changes the database directly). Marking stores readonly in such a way would mean that an accidental coding error would result in a repeatable ProgrammingError, rather than an occasional (ie, thread execution order dependent) OperationalError("database is locked"). It could also help lead to clearer code.

To get a readonly store, a "readonly=1" option would be added to the URI used to open the database - all stores derived from that database would then be readonly.

Stuart Bishop (stub) on 2009-06-27
summary: - SQLite could usefully support readonly Stores
+ Storm could usefully support readonly Stores
Stuart Bishop (stub) wrote :

I have a similar use case where I have read-only slave PostgreSQL databases.

At the moment, we are using a customized storm.databases.postgres.Postgres that issues a SET DEFAULT_TRANSACTION_READ_ONLY TO TRUE on connection.

ZStorm can make use of this too. No need to commit a Store with a read-only Database (or a read-only Store), just rollback instead and no need to get involved in two phase commit.

So for Launchpad, I probably will not be able to use such a feature soon (We will need to be able to create and modify temporary tables on the slave databases, despite all the persistent data being read-only). But it is worth making this feature available to all backends rather than a SQLite only extension switched on via the connection URI.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers