Archive for the ‘Technology’ Category

Gotcha: nHibernate NonUniqueObjectException

Quick note on a gotcha. Was getting the infamous NonUniqueObjectException: a different object with the same identifier value was already associated with the session from NHibernate.

Typically, this error occurs when you are using objects across NHibernate ISession’s. In my case, I was using the same ISession but was still receiving the error when I added two New objects to a parent object’s collections.
After running through “there must be another session being created” thought over and over, I finally discovered that the ID mapping for the child object did not have a generator assigned. I’m guessing this was causing NHibernate not to realize that when id equaled 0 it was transient. In my implementation, I just included logic to always make sure the child object’s identity is unique and allow the database to resolve the actual identity for the next session.

An interesting red herring that I’m glad to be rid of.


Debugging is a code smell

Production can be a real pain in the ass. This seems to get amplified if the software being run in production doesn’t do its job of telling you what’s wrong. Something I’ve noticed during my tenure at a software company I worked for, is that the product regularly required a developer to be involved in order to determine configuration issues.

Usually the developer needed to hop on a webex and walk through the problem with the Client’s support staff. This was no small feat, as the support staff required programmers, DBAs, and the client Project Managers to be involved – not the kind of situation that instills confidence for your client.

If the problem could not be determined, a copy of the production database (that was usually 10-50 gigs) would need to be scrubbed, and transported so that development could debug the situation locally in order to find out what’s wrong. This seemed ridiculous, and was actually indicative of a larger problem: There was no visibility into what the code was actually doing.

How do you combat such a horrible problem? Slowly.
Unfortunately, there is No Silver Bullet. Buy in needs to be available to fund the necessary steps to identify critical areas of the application that are continually bad performers and address them.

How to address them?
Unit testing comes to mind. Identify areas of your system with high coupling and attack. Focus on what’s best for the BUSINESS. Create a wish list that would help the BUSINESS if more transparency were available.

All in all, its all been said before. I would recommend looking at: The PPP, Clean Code and Refactoring.

Command Query Separation(CQS) Presentation

Just recently watched Greg Young’s presentation on Command Query Separation I have been lurking on the Domain Driven Design Yahoo group for a bit, and had seen back and forths about CQS but hadn’t fully followed the concept until seeing this presentation. It was quite eye opening.

The presentation is here, I would highly recommend watching it.

nHibernate: Component MetaData

Adding some auditing events to nHibernate through its new event system. A particular requirement of the auditing implementation needs the component types be unwrapped and audited along with the parent object. As a first entry into the nHibernate metadata, I found that calling GetClassMetaData() for a component type would return a null reference, since the component is not an entity.

Instead, if you use the Property’s IType for the component, you can cast it down to a NHibernate.Type.ComponentType. This will then allow you to access the Propery names and values for a component object.

Fun stuff.

Gotcha: Connection Property on ADO.Net Transaction

In a recent project, the application utilized a custom Data Access Layer that provided an API for managing connectivity to the database. The API had an abstract definition that business logic would call into in order to define the explicit Unit of Work boundaries that were being performed. This forced the business logic to create an abstract transaction object to begin, create or rollback the unit of work. The concrete implementation had connectors for both MSSQL and Oracle that manipulated the respective ADO.Net libraries.

The Transaction class for ADO.Net has a property for a connection reference. When an abstract transaction was started, the concrete implemalentation would create a new OracleConnection or SQLConnection and then grab a transaction from that. Once, the transaction had ended the connection property would be checked if still available, and if it was – it was closed.

At a client site, we started noticing connection leak messages were appearing in the application. When checking the open sessions for the user, it was found that the connections would quickly reach the default maximum of 100. I managed to narrow it down to the fact that the concrete implementation of the transactions was the cause. Upon further investigation, I found that when an ADO.Net transaction is committed, it will lose its reference to the connection, and since the connection was not being garbage collected fast enough within this tight loop, the pool limit would be hit. Once this was resolved by holding an explicit reference to the connection, the open connections went down drammatically and all was right in the world.