Brian Hartsock's Blog

In ASP.NET, it is quite common to need to store information in the context of a single web request. For example, a NHibernate session should usually exist for one web request. HttpContext is the tool for accomplishing this.

But what happens when you have code embedded in business logic that might not always be running in an ASP.NET web application? HttpContext isn’t valid, so you can’t use it. Why not use CallContext, since HttpContext uses this anyways?

I was starting to convert some of my code to use this, when I found this article. Apparently doing this works most of the time but can cause some nasty bugs since ASP.NET can switch HttpContext‘s without switching CallContext‘s.

Instead, code that could be called from ASP.NET and other applications should first check for context.

1
2
3
4
5
6
7
8
9
10
11
12

if(HttpContext.Current == null)
{
     //Using CallContext example since not in ASP.NET
     CallContext.SetData("blah", new object());
     object contextData = CallContext.GetData("blah");
}
else
{
     //Using HttpContext example since in ASP.NET
     HttpContext.Current.Items.Add("blah", new object());
     object contextData = HttpContext.Current.Items["blah"];
}

In fact, I will probably end up writing a static class to implement this so code doesn’t have to constantly check whether or not in an ASP.NET session.

NMS is the .NET client library for using ActiveMQ, as well as other messaging systems. Unfortunately, it is the only complete one that I found, so using it isn’t really a choice (although I recommend coding your own STOMP client). I encountered many problems using it, but after working through them, everything seems to work.

Problem #1 – Downloading

Almost all the links to NMS point to Sprint.NET’s NMS build. If you notice the date in the link, the last time it looks to have been built is March 20, 2007. Also, almost all the links are broken on this site, which is never a good sign.

Instead, just download from Apache NMS . Since they don’t have releases, just checkout from SVN (https://svn.apache.org/repos/asf/activemq/activemq-dotnet/). Note that the link on their website points to (https://svn.apache.org/repos/asf/activemq/trunk/) which isn’t NMS.

Problem #2 – Application Hang

One issue that exists with the NMS library is a race condition when sending synchronous messages. Basically, when sending a synchronous message, if the transport connection dies after sending, the application waits forever. Luckily I found this article which tells you how to prevent it. The Apache NMS documentation doesn’t mention it, but there is a query parameter that can be added to the connection URI that will timeout synchronous calls. So the URI would look like tcp://myactivemqserver.com:61616/?transport.requesttimeout=10000.

Even though this fixed the problem, it annoys me because it is very easy to fix without having to use a timeout parameter. I am thinking about trying to get a patch applied to the library but until then, just email me if you want to know the fix.

Problem #3 – Transport layer death

Even though request timeout fixes multitudes of problems, I want to make sure that the connection is destroyed in the event of any error. It isn’t documented very well, but this ExceptionListener event will bubble up anytime an error occurs in the transport thread and the socket gets closed.

1
2
3
4
5
6
7
8
9

//Create connection
IConnectionFactory factory = new ConnectionFactory(uri);
this.connection = factory.CreateConnection();
 
this.connection.ExceptionListener +=delegate(Exception e)
{
     this.connection.Dispose();
     this.connection = null;
}

There are two problems with doing this though. One, it isn’t very thread safe because the delegate WILL get called from a different thread. NMS is a multi-threaded library and there is no way around this. Thread safety should be handled better, but this is a trivial example to show the concept of the ExceptionListener event. Two, this event will get called if ActiveMQ returns an Exception message, which sometimes aren’t fatal. Normally, I have only seen these when disconnecting so just detach the event handler from the event before closing the connection.

Ten years ago, Java was the next big thing. It had portability and was purely object oriented, both of which were needed at the time. Today I found an article discussing Sun’s recent acquisition of two Python developers. Their main goal is making Python work on the JVM. This go me thinking, is Java trying to play catch-up to .NET?

Don’t get my wrong, I know Java is a very widely used platform, but what has really changed in the past few years with Java? I might just be ignorant on the matter, but I haven’t heard of much. .NET on the other hand seems to be the face paced new comer when it comes to platforms for development. The feature-set in .NET Framework 3.5 is quite simply amazing. Not to mention, it supports a multitude of languages, soon to be including Python and Ruby.

But, I can’t entirely say I support .NET. The one thing that kills me is its ties to Windows. I know, Microsoft doesn’t have much of a reason to port it to other operating systems, but this gives Java a huge leg up. Even though Mono exists, it is barely keeping up with .NET Framework releases.

No matter which doctrine you subscribe to, competition is a good thing and will only make each platform better. I look forward to watching both closely over the next few years.

To all my Java and Linux friends, feel free to leave flaming comments.

In a previous post I talked about my first impressions of NHibernate. Not a whole lot has changed since then, except I have learned a lot more. But, I said I would discuss what I didn’t like about NHibernate so here it goes.

Session Management

The biggest thing that I don’t like is the session management aspect. Although I have come to understand why NHibernate sessions are so valuable and critical to its functionality, it doesn’t stop the fact that persistent objects are tied to a single database. For a project that follows the patterns and practices set forth in ivory towers, this works great. All business entities are stored in a database in 6th normal form and everyone is happy. Well, when working with legacy and enterprise systems, that usually isn’t the case. There are many different databases that are used and objects are stored across a variety of them.

In order to get my system to use NHibernate, the first challenge was incorporating multiple sessions. A session is basically a connection to a single database that manages persistent objects. This article describes a really complex way to accomplish it, but all you really need to pay attention to is the NHibernateSessionModule and NHibernateSessionManager. Using the outline described in the article, I successfully got multiple sessions to work fairly painlessly.

The second challenge was storing a persistent object in multiple database. Since persistent objects in NHibernate can’t span multiple sessions, some data massaging has to be performed. As I see it, there are two possibilities for storing an object in multiple database.

1. Different objects for each database with type conversion operators
2. The same object for all databases with extra session logic

The latter is obviously easier from a domain model perspective, but not from an implementation perspective. For a persistent object from one session to be stored in another session, all references must be removed from the session. This means unproxying the object and unpersisting any collections contained within the object. Looking through the NHibernate source code, I was able to accomplish this with only a few lines of code.

Setup & Documentation

Most of the getting started guides for NHibernate are no where near complete or up-to-date. It took a couple days to get my environment up and running. This isn’t really a problem with the library itself, but is still a problem for first time users. In all reality, there seems to be a lack of documentation in general. Three example mappings in the documentation is no where near enough for what is marketed as an enterprise ORM solution.

Conclusion

NHibernate is awesome. Even with these minor issues, it is one of the greatest tools for web development I have ever used. I hope that the development of this library continues to improve, and hopefully some of these issues will be resolved.

Today I ran into a few problems while writing test cases for NUnit. I kept receiving reflection errors and the exceptions were too vague to help me fix the problems. Luckily, I found an article on debugging while testing with NUnit. Works like a charm.

Update…
If you use TestDriven.NET you can just click on a project and use Test With->Debugger. It has the same effect and is much easier than the above article.