Storm could usefully support readonly Stores

Bug #137116 reported by Richard Boulton
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Storm
New
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)
summary: - SQLite could usefully support readonly Stores
+ Storm could usefully support readonly Stores
Revision history for this message
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.