- From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
- Date: Mon, 31 Aug 2009 14:34:56 -0700
- To: Web Applications Working Group WG <public-webapps@w3.org>
- Message-Id: <F977FD4C-531E-42F1-80EC-AA2CD0964FCF@oracle.com>
After studying the current error codes in the WebDatabase spec, it is
clear that they are neither an exhaustive, nor a systematic
arrangement. As a result, applications will have a hard time
performing recovery with or without user help. To improve on this, I
analyzed the JDBC SQL exception hierarchy and matched it against the
WebDatabase spec.
Here are my findings about the main categories of exceptions and their
causes:
Non transient exception - a retry of the same operation would fail
unless the cause of the SQLException is corrected
Non transient connection exception - the connection operation that
failed will not succeed when the operation is retried without the
cause of the failure being corrected.
Syntax error exception - in-progress query has violated SQL syntax
rules.
Integrity constraint violation exception - an integrity constraint
(foreign key, primary key or unique key) has been violated.
Data exception - indicates various data errors, including but not
limited to not-allowed conversion, division by 0 and invalid arguments
to functions.
Feature not supported exception - UA does not support an optional
WebDatabase feature
Serialization exception - an error with the serialization or de-
serialization of SQL types or with the size of the data being returned
Recoverable exception - a previously failed operation might be able to
succeed if the application performs some recovery steps and retries
the entire transaction
Transient exception - a previoulsy failed operation might be able to
succeed when the operation is retried without any intervention by
application-level functionality.
Timeout exception - the timeout has expired without obtaining
necessary locks.
Transaction rollback exception - the current statement was
automatically rolled back by the database becuase of deadlock or other
transaction serialization failures.
Of these exception conditions:
VERSION_ERR corresponds to the Non transient connection exception
condition
SYNTAX_ERR corresponds to the Syntax error exception condition
CONSTRAINT_ERR corresponds to the Integrity constraint violation
exception condition
TOO_LARGE_ERR corresponds to the Serialization exception condition
QUOTA_ERR corresponds to the Recoverable exception condition
TIMEOUT_ERR corresponds to the timeout exception condition
On the other hand, the following errors say nothing about what the
application can do:
UNKNOWN_ERR and DATABASE_ERR
Here is a proposal for error codes that allows better recovery for
applications:
Constant, Code, description
NON_TRANSIENT_ERR, 1, cannot retry statement as is
VERSION_ERR, 2
SYNTAX_ERR, 3
CONSTRAINT_ERR, 4
DATA_ERR, 5
FEATURE_ERR, 6
SERIAL_ERR, 11, change something about the size of the result set to
continue
TOO_LARGE_ERR, 12
RECOVERABLE_ERR, 21, retry after taking some user action
QUOTA_ERR, 22
TRANSIENT_ERR, 31, retry after some time, without needing any user
action
TIMEOUT_ERR, 32
Since the UNKNOWN_ERR is unrelated to the database itself, I think we
can leave it unchanged. I do think that either DATABASE_ERR has to
clearly state the kind of problem that occurred, or else
Since the error codes in SQLException are local to WebDatabase, we
would need an additional state variable in the SQLException exception
that would identify the kind of problem encountered in the
implementation. XOPEN and SQL:2003 provide a full scheme of
identifiers that can be used for such reporting, which is needed in
applications so that appropriate action can be taken.
Based on both the above points, here's a proposed IDL for SQLException
exception SQLException {
const unsigned short UNKNOWN_ERR = 0;
const unsigned short NON_TRANSIENT_ERR = 1;
const unsigned short VERSION_ERR = 2;
const unsigned short SYNTAX_ERR = 3;
const unsigned short CONSTRAINT_ERR = 4;
const unsigned short DATA_ERR = 5;
const unsigned short FEATURE_ERR = 6;
const unsigned short SERIAL_ERR = 11;
const unsigned short TOO_LARGE_ERR = 12;
const unsigned short RECOVERABLE_ERR = 21;
const unsigned short QUOTA_ERR = 22;
const unsigned short TRANSIENT_ERR = 31;
const unsigned short TIMEOUT_ERR = 32;
unsigned short code;
DOMString sqlState;
DOMString message;
};
Nikunj
http://o-micron.blogspot.com
Received on Monday, 31 August 2009 21:37:30 UTC