Sunday, May 23, 2010
blog->restart()
Saturday, March 6, 2010
LINQ
Saturday, February 27, 2010
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.
ConstraintViolationException
is the base exception for SQL constraint violations.CheckConstraintViolationException
denotes violation of acheck
ornot null
constraint.ReferentialContraintViolationException
denotes a violation of aforeign key
constraint.UniqueConstraintViolationException
denotes a violation of aunique
orprimary key
constraint.
ReprocessableException
is the base exception forTransactionSerializationFailureException
andDeadlockException
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.
Friday, February 26, 2010
PostSharp is going closed source
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.
Thursday, February 25, 2010
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.