- 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