perhaps it would be prudent to change the spec to at least suggest
that if a database becomes "known to be corrupt," operations on
all open handles to that database should start throwing
INVALID_STATE_ERR exceptions.
I think this is already specified:
3. If transaction has been marked as "bad", then raise an
INVALID_STATE_ERR exception.
...
7. If the statement execution fails for some reason, transaction
must be rolled back and marked as "bad".
I think you can reasonably consider a statement on a corrupt
database to have "failed for some reason."
After all active transactions are cleared, there is no context that
remembers that the database is corrupt, and the next statement to be
run would actually attempt to be executed.
I suppose user agents can volunteer to remember this and
automatically fail the next statement, but it's certainly not
specified.
Are you proposing that, once a database has been corrupted, all
transactions executed on it should fail, raising an INVALID_STATE_ERR
exception, for all time?
Once all active transactions are cleared, there's no need to remember
that the database was corrupt. The user agent should simply recover
from the corruption in an implementation-defined way -- either by
deleting the database, performing an error-recovering integrity check,
asking the user to install cosmic ray shielding around the house, or
something else.
Geoff
