Unified storage level exceptions

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.

Constraint violations:

• ConstraintViolationException is the base exception for SQL constraint violations.
• CheckConstraintViolationException denotes violation of a check or not null constraint.
• ReferentialContraintViolationException denotes a violation of a foreign key constraint.
• UniqueConstraintViolationException denotes a violation of a unique or primary key constraint.

Concurrent access errors:

• ReprocessableException is the base exception for TransactionSerializationFailureException and DeadlockException
• DeadlockException will surely be used very often, it’s thrown when you got into a deadlock with other transaction working on the same data.
• TransactionSerializationFailureException denotes any concurrent access problem except deadlock.

General errors:

• ConnectionErrorException is thrown when there is something wrong with the database connection.
• SyntaxErrorException is thrown when RDBMS was not satisfied with the supplied SQL query :-)
• OperationTimeoutException is 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.

PostSharp is going closed source

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

"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.

Oracle challenge

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 ORA-08177.

However, I'm still getting this error during heavy inserts, so I'm forced to use read committed isolation level instead.

Yep, I'm here

Hello, all. My name is Denis Krjuchkov. I am one of the developers in DataObjects.Net team. This is my personal blog about software programming in general and DataObjects.Net in particular. Alex Yakunin, Dmitri Maximov and Alex Kofman write mainly about using DataObjects.Net. I'm going to write more about how DataObjects.Net is designed and implemented. Have fun reading.