Sunday, May 23, 2010
Saturday, March 6, 2010
Saturday, February 27, 2010
With previous versions of DataObjects.Net v4.x there was no way to handle database errors in one fashion. All ADO.NET exceptions (like
SqlException for SQL Server or
NpgsqlException for PostgreSQL) were passed to user code simply wrapped in
StorageException. These times have gone. Upcoming DataObjects.Net v4.2 will support a nice new feature. We called it "unified storage level exceptions". As the name suggests all ADO.NET errors are now unified.
Here are the exceptions you could expect. They are naturally grouped by cause of error.
StorageException is the base exception for all storage errors.
ConstraintViolationExceptionis the base exception for SQL constraint violations.
CheckConstraintViolationExceptiondenotes violation of a
ReferentialContraintViolationExceptiondenotes a violation of a
UniqueConstraintViolationExceptiondenotes a violation of a
ReprocessableExceptionis the base exception for
DeadlockExceptionwill surely be used very often, it’s thrown when you got into a deadlock with other transaction working on the same data.
TransactionSerializationFailureExceptiondenotes any concurrent access problem except deadlock.
ConnectionErrorExceptionis thrown when there is something wrong with the database connection.
SyntaxErrorExceptionis thrown when RDBMS was not satisfied with the supplied SQL query :-)
OperationTimeoutExceptionis thrown when server spent too much time executing your query and ADO.NET client decided it can not wait any longer :-) This exception probably denotes a live lock.
There are other descendants of
StorageException but they are not related with database communication and are not shown here.
Friday, February 26, 2010
Here is the original post. After many years being open source famous AOP library for .NET is going to be proprietary. It is sad. I guess fork of GPL/LGPL licensed 1.x branch will be created soon by enthusiasts who can’t live with proprietary PostSharp. It’s going to be an interesting battle :-)
"Practice of functional programming" is young but very interesting Russian online magazine about functional programming. Despite its name it covers theoretical aspects as well. Recently, a new issue has been published so unless you are not familiar with Russian language, download a copy and start reading.
Thursday, February 25, 2010
During DataObjects.Net development I've faced a very annoying Oracle "feature". It is a well-known fact that Oracle implements a multiversion concurrency model. It keeps old versions of modified data (in so called "undo segments") for transactions that need them. I'm omitting the explanation of Oracle MVCC concepts as they are described in details in appropriate books. The rest of the post assumes you are familiar with them. I'm going to tell you about one not so common pitfall when using Oracle.
Here is the "feature": sometimes during index restructuration undo data becomes unavailable. Transaction that runs in
serializable isolation level and requests data that is somehow related to such index gets
ORA-08177: can't serialize access for this transaction error. A good explanation can be found in this thread. This can even happen when only one session is accessing database.
What is the solution? Recent versions of Oracle supports
rowdependencies clause for
create table statement. By default Oracle retains SCN for each data block. So all rows in the block have the same SCN.
rowdependencies clause slightly changes structure of the table preserving SCN for each row independently. Using
rowdependencies clause decreases chance of getting
However, I'm still getting this error during heavy inserts, so I'm forced to use
read committed isolation level instead.