Introduction

Garbage Collection sure is great, isn’t it? We don’t have to keep track of all the memory we’ve allocated and we don’t need to release that memory when it’s no longer needed. Because that is after all what the Garbage Collector does for us, without us having to worry about it. This is actually a widespread misconception among many .NET developers. It’s true that Garbage Collection makes memory management a lot easier, but we simply can’t rely on it all the time. There are most certainly some things you must always keep in mind when it comes to memory management in .NET.

Different Kinds Of Resources, Different Consequences

In most pieces of code, you use variables. A lot of these variables are references to objects. When your variables go out of scope, they no longer exist. When those variables are references to objects, only your reference is gone and the actual object that was referred to is still in memory somewhere. The Garbage Collector (GC) makes sure that orphaned objects (objects that no longer have a usable reference to them) are removed from memory. This is an automatic process within the .NET runtime. Essentially, the GC periodically performs some checks on objects and if it comes to the conclusion that certain objects are no longer needed, it will remove them from memory. This is a gross oversimplification of how it really works, but that is what it comes down to and that is also how most people think about the GC.

The GC in .NET is very smart and will almost always do a better job of memory management than you will. But there is one huge downside to it: the GC runs periodically and you have no deterministic way of knowing when it will run. Sure, you can instruct the GC to perform a collection but in most cases that will actually have a negative impact on the memory management of your application. I won’t go into the details here, but i will provide a follow-up post on this later on. For now, keep in mind that forcing a garbage collection to occur is really something you should avoid.

So is it really a problem that you don’t know for certain when the GC will run? It depends on which kind of objects that need to be removed from memory. There are basically 2 kinds: managed and unmanaged resources. Managed resources are typical .NET types. Unmanaged resources (also referred to as Native Resources) are things that fall outside of the scope of the .NET managed environment. These are usually things that are available within the Operating System, or that are available through lower-level development API’s (such as the Win32 API for instance). Unmanaged resources can’t be cleaned up automatically by the .NET runtime, so if you use them directly, you are responsible for cleaning up after you’ve used them. Luckily, a lot of managed types are available that take care of the dirty details for you. For instance, if you need to use a file in .NET, you’ll typically use a FileStream instance or something else that easily makes the content of the file available to you, or that easily allows you to write content to a file. The FileStream is a managed type, but it uses unmanaged resources to implement the functionality it offers.

Now think about this: you are using a managed type, so you shouldn’t need to perform any cleanup, right? However, if that managed type uses unmanaged resources then they still need to be cleaned up. And those unmanaged resources should be cleaned up as soon as possible because they can be quite expensive. These types usually offer a way to clean up the unmanaged resources they use in a deterministic manner. They usually implement the IDisposable interface, which exposes a Dispose method. When you call the Dispose method, the unmanaged resources are cleaned up right then and there and then there’s no need to wait for the garbage collector, which again, could be quite expensive when you (either directly or indirectly) have a bunch of unmanaged resources in memory that are waiting to be cleaned up.

Disposable Managed Resources

I call types that implement the IDisposable interface Disposable Managed Resources. They are indeed managed types and thus they are guaranteed to be cleaned up when the GC comes around and notices that instances of these types are no longer needed. However, if you merely trust on the GC to clean up instances of these types you are taking quite a risk. Any expensive resource it may hold might be cleaned up a lot later than it could have been. Which can be very inefficient, and thus, quite costly.

If a type implements the IDisposable interface, it usually has a good reason for doing so (there are of course exceptions to the rule). It is essentially a way of telling consumers of the type that it offers a deterministic way of cleaning up the resources it consumes and i believe you should take advantage of that. If you don’t, you may end up with inefficient memory management, and that’s when people start complaining that Garbage Collection is ‘evil’ or that it ’sucks’. In most cases, people who feel that way simply don’t know how to use it properly. The IDisposable interface and the Dispose Pattern (which we’ll get to in a minute) allow you to avoid most of the issues that are generally attributed to the Garbage Collection in general.

So how do we deal with this? First of all, if a type uses unmanaged resources, it should implement the IDisposable interface using the Dispose Pattern. Secondly, if any of your types use other types that implement IDisposable, it is your responsibility to make sure these types are properly disposed of. You either dispose them when you no longer need them, or you must implement IDisposable and the Dispose Pattern yourself to make sure the Disposable Managed Resources you depend on are indeed properly disposed of. If you need to implement IDisposable, your type effectively becomes a Disposable Managed Resource itself. A lot of people think that this isn’t necessary, but by not doing so they are breaking the contract that the IDisposable interface implies. If a type implements IDisposable then either that type or any other type it may use probably uses unmanaged resources somewhere and you want to see these get cleaned up as soon as possible. Because of that, i believe it’s best to implement IDisposable yourself if you’re holding any reference to a type that also implements it.

The Dispose Pattern

Implementing the IDisposable interface can be as easy as merely providing a public Dispose method where you perform your cleanup. That’s really not a good way of doing it though, as it could lead to a bunch of other problems which might actually make the situation worse. The best way to implement the IDisposable interface is to implement the Dispose Pattern, which looks like this:

If you don’t need a finalizer it’s best not to provide one (we’ll discuss finalizers later on). If you do need one, you would implement it like this:

So what’s so good about the Dispose pattern? Well, we make a clear distinction between what should happen when the object is disposed through the Dispose method, or when it’s being cleaned up by the finalizer. When the clean up occurs through a call to Dispose, it calls the protected virtual Dispose method with the disposing parameter set to true. When this parameter is true, you should call the Dispose method of each Disposable Managed Resource you’re holding a reference to. Outside of the if-statement, you should clean up each unmanaged resource you may be holding.

If your class (or a derived class) implements a finalizer method, it should call the Dispose method with the disposing parameter set to false. The reason for this is that the order in which objects are finalized is not specified. If you’re not careful, you could accidentally call the Dispose method of a Disposable Managed Resource which may have already been finalized as well. This would cause an exception and a finalizer method should never ever throw an exception because that could keep other objects from being finalized.

If you can, try to put this pattern into a reusable base class and make your Disposable Managed Resource holding types inherit from this. An example of this approach can be found here.

Using Disposable Managed Resources

In a lot of cases, you will use a Disposable Managed Resource within the scope of one method. In that case, you certainly don’t need to implement IDisposable. There are two things to keep in mind though. If you receive the Disposable Managed Resource as a method parameter, you are not responsible for disposing it! Somebody else created it, let them take care of the disposal. Things will most likely go wrong if you dispose objects that have been giving to you by somebody else. So in this case, you would just use the object and not worry about it any further:

However, if you create the object yourself, then you are responsible for getting rid of it properly. In that case, use a using block to make sure the object is disposed of even in case of unhandled exceptions:

In case you don’t know, the using-block guarantees that the Dispose method will be called when we leave the scope of the block. It can get pretty tricky sometimes if you’re passing the Disposable Managed Resources to other objects that will hold a reference to them which will remain in use after you’ve left the using block. In this scenario, it’s possible that the object you’ve passed the Disposable Managed Resource to will try to invoke methods on the disposed instance. Also a situation you most certainly want to avoid because it will either cause unexpected behavior or even unhandled exceptions. The unhandled exceptions are easy to figure out, but the unexpected behavior might be difficult to debug. The key in this scenario, is to figure out a way to not call Dispose on the resource until the other object is done with it. Sometimes it might be enough to put your using block on a slightly higher level, other times you’ll have to keep a reference to the resource yourself, which effectively means you’ve now become an owner of the Disposable Managed Resource.

Owning Disposable Managed Resources

If you need to hold a reference to a Disposable Managed Resource, you are either the owner of the object or at least someone who owns a stake in the lifetime of the object. If you are the owner, and you do not pass the Disposable Managed Resource to any other object then the solution is easy: implement IDisposable. If you do pass the Disposable Managed Resource to other objects, then it can get tricky. Will they only use it to perform some action or will they hold a reference to it? If they hold a reference to it, it means that they too have a stake in the lifetime of the resource. Depending on the implementation of the other types, they may or may not call the Dispose method of the instance you created. Which could cause unexpected behavior or exceptions in your code. Make sure you are prepared for that if you’re passing these objects around. But you should definitely dispose of them in your own Dispose method.

If you didn’t create the Disposable Managed Resource, but you do need to hold a reference to it, then you’ve got some questions to answer. Does the type which provided you with the instance expect you to be solely responsible for the lifetime of the object? In case of factory classes or factory methods, the answer is usually ‘yes’. If you’ve been given the instance by something that will probably make use of that same instance, i think it’s better not to dispose it. Some people will probably disagree, but i don’t think it’s my responsibility to dispose objects that i didn’t create, unless the instance was given to me by a factory class or a factory method. I would expect that the real owner of the resource would dispose of it. Still, it’s a difficult call to make.

Finalizers

Finally, i’d like to add a few words about Finalizers in .NET. A finalizer is similar to a destructor in C++, in that it is the code that is run when your object is being removed from memory. The big difference is that you never know for sure when it will be run, which is why the IDisposable interface and the Dispose pattern was created. There are a lot of misconceptions going around about finalizers, so keep the following comments in mind.

First of all, finalizers only make sense when you have direct references to unmanaged resources. If you have unmanaged resources, implement IDisposable and provide a finalizer that calls the Dispose overload with the disposing parameter set to false. This should really be the only code inside your finalizer method.

Finalizers also come with a performance penalty. When finalizable objects are created, pointers to these objects are added to the finalization queue of the GC. These finalizable objects are collected less frequently because the GC performs finalizations through its finalization queue. This finalization process is not executed as frequently as regular garbage collections because it’s quite costly. So not only are finalizable objects cleaned up less frequently, it takes more processing power to do so. So if you have a lot of finalizable instances, your code’s performance can easily be impacted because of this.

Conclusion

I hope i made it clear that there is a lot more to automatic memory management in .NET than simply relying on the GC to take care of all of the details for you. There is a lot more stuff that i didn’t cover in this post (it’s long enough already) but most .NET developers will probably get by pretty well with the advice given in this post. It’s not an easy subject to explain so i hope everything was clear

The usual example:

Thanks to my request/response service layer, those are two service requests that will be performed in one service call. On the server side, these two requests are dealt with separately. But they merely retrieve data from the database. Wouldn’t it be cool if those 2 queries were performed in one database roundtrip instead of two? Wouldn’t it be cool if we could batch the queries that will be performed by read-only service requests into a single database roundtrip? It sure as hell would be. Implementing this was one of those irresistible challenges you just can’t say no to, so from now on we can actually do this. I’m not gonna get into the actual implementation of how I got it working (check the code in the library for that if you’re interested), but i will show you how you can do this in your application.

First of all, if you have requests that merely return data, inherit from ReadOnlyRequest instead of the usual Request type:

The handlers for these requests should inherit from the ReadOnlyRequestHandler base class instead of the usual RequestHandler class. Btw, my ReadOnlyRequestHandler class inherits from my UoWRequestHandler class, which requires a IUnitOfWork instance to be passed to the constructor. So we need to put an IUnitOfWork parameter into the constructor along with our other dependencies if we want the IOC container (or the request processor) to pass us a valid IUnitOfWork instance.

The ReadOnlyRequestHandler class defines two abstract methods: the AddQueries and GetResults method. Both are passed an instance of IQueryBatcher and the actual request object so you can use the request parameters if there are any.

In the AddQueries method, you simply add the queries this request needs to perform to the batcher (with a string key value of course for later retrieval), and in the GetResults method you can get the results (with the key values used in AddQueries) back from the batcher and you can construct your Response object. The GetResults method will be called after each ReadOnlyRequestHandler for the current request batch has added the queries to be performed to the batcher. The queries are then all executed, and each ReadOnlyRequestHandler will have its GetResults method called so each handler can construct the proper response.

And that’s it basically… The calling code doesn’t even change.

Now there are obviously some limitations. If you mix ReadOnlyRequests with other Requests, then each ReadOnlyRequest will be handled as if it were a regular Request and they will each get their very own IQueryBatcher instance. I don’t think there’s any strategy to automagically determine which ReadOnlyRequests can be batched together while still correctly executing the other Requests since those requests might influence the results of ReadOnlyRequests that are present further in the batch.

Anyways, you can find an updated version of the library here. Check it out, it’s some pretty slick shit, if i do say so myself

Note: i only added this stuff today, so the previous build (080729) doesn’t have this yet, in case you only downloaded that today, and the stats show that some of you actually did download it

The first take was pretty good, after all it got Ayende-d which is the highlight of my blogging career so far :). In his post, he was pretty positive about my implementation, with one small exception:

“About the only thing that I would strive to improve there would be the need to explicitly register request & replies. I would try to get something convention based there. Maybe something like Request, and then have IHandler and route the whole thing through the container again.”

Let’s give that a shot

Previously, the base implementation of the service routed the call to the correct RequestHandler like this:

And then the service implementation would provide an implementation of the GetHandlerTypeFor method. In that implementation, you somehow had to map the type of the incoming Request to a handler. In the code that i posted i used a dictionary-based approach. You could’ve used a couple of if statements as well. The point is that you had to do that mapping which is indeed somewhat annoying.

First, we’ll add a new interface on top of the IRequestHandler interface:

We also modify the base RequestHandler class to provide a derived generic class:

The only reason why i still have the base RequestHandler type is to make it easier to register the RequestHandler types with the container (which i’ll show below).

A specific RequestHandler can now be defined like this:

Right, now we can register all of our RequestHandler types with the container:

So now each generic RequestHandler type is registered through the generic IRequestHandler type.

Our base Service implementation now looks like this:

And now you no longer need to map the Request type to the RequestHandler type yourself since the container now takes care of that for us.

Picking up where we left off with the WCF batching… We had the following code client-side to execute a few service methods with one request:

Similar to my query batcher, i wrote this simple WCFCallBatcher class:

and now we can rewrite the client code like this:

Yes, we’ve got more lines of code now, but i like this block of a code a lot more than the earlier one. This is much more readable.

What happens if you have the following code client-side:

The service variable is a reference to a WCF service proxy. This means that this causes 2 remote service calls. I really hate unnecessary/excessive roundtrips, so i would rather retrieve this data from the service in one roundtrip. Unfortunately, this is not something that is supported by WCF out of the box, so if you want to do this you have to do it yourself. There are a couple of options, so i started browsing the web. Once again, it’s Ayende to the rescue. The approach he suggests is a bit cumbersome compared to how you’d normally design your services, but it does offer a great deal of flexibility and it allows you to nicely batch your requests. So i figured i should try implementing this approach.

The idea is to provide a service method that looks like this:

Each Request corresponds to what used to be a normal service method, and this method returns a Response for each Request. In Ayende’s post, he suggest offering this as the only service method. I won’t go that far though. I’ll offer this method, and each ‘normal’ method allthough those methods will also use Request types as input variables and Response types as return values. The idea is to be able to use each service method individually, or to have multiple service methods executed in one roundtrip through the Process method.

We need a way to define Requests and Responses, so we create the following classes:

For now, these are empty but i’m pretty sure i’ll add a few members to these later on. Then we define specific Request and Response types for the functionality our service needs to offer:

We then create a base interface that each service will implement (along with more specific service interfaces):

The KnownTypeProvider is responsible for providing a list of types that should be treated as KnownTypes during serialization/deserialization. We could also list each type that derives from Response/Request but that will become a long list, so i went for this approach. The code of the KnownTypeProvider class looks like this:

Our real service now looks like this:

To handle these requests, i came up with the following RequestHandler type:

And the implementation of one of these concrete RequestHandlers looks like this:

Now we have to make sure we can actually use this RequestHandlers in a generic manner. I came up with the following base class for my services:

And the real service then looks like this:

At this point, using a dictionary to map the Request types to the RequestHandler types seems silly, but this is just a small part of the service, more methods will be added so more Request and RequestHandlers will be handled, and in that case i prefer to use a dictionary lookup over a big if statement

So now i can do this client-side:

And it only uses one remote call which will be much better for performance. At this point, the syntax is not so nice, but i’ll probably provide something similar to my query batcher class so that should improve readability.

So that’s pretty much it… it takes some effort to set this up, and there’s still more to be done (dealing with exceptions in one of the requests for instance) but once you’ve got it set up, i kinda like it. Sure, implementing service methods takes more code than it used to because of the extra classes involved, but they do offer a few very important benefits. You may have noticed that the RequestHandler types receive all of their dependencies through the constructor, and that they are created through the IoC container. This means i can very easily add/remove/change dependencies in my handlers without having to modify code in other places. It also means i can test my service implementations in a thorough manner while providing mocked dependencies instead of the real ones. Another big advantage is that i can add optional parameters to my Request types and thus, offer more functionality through my RequestHandlers without having to update the services and the proxies.

So all in all, while this approach requires to you write more code at first, i think it might actually end up giving you more flexibility for changes later on, while offering you much more control over certain performance characteristics.

Everytime i need to implement the IDisposable interface i have to lookup the recommended way of doing so. That in itself is a bad sign, so i figured i might as well get rid of this by putting the implementation in a reusable base class, based on the officially recommended way:

So now i can simply inherit from Disposable, and i just need to implement the two abstract methods. Here’s a made up example to illustrate this:

Obviously, you can’t use the Disposable base class if you’re already inheriting from another base class so in that case you’d still have to implement the IDisposable interface.

Update: Here’s a thread-safe version of this idea.

One of my favorite NHibernate features must be the MultiCriteria/MultiQuery support. This basically allows you to execute a set of queries in one database call. In case you don’t know, an ICriteria instance is basically a programmatic query. If you use MultiCriteria, you can batch either ICriteria or DetachedCriteria instances. And if you use MultiQuery, you can batch regular HQL strings, IQuery instances (which are in fact also HQL queries) or references to named queries.

That gives you quite a few options to batch your queries. The only downside to using MultiCriteria and/or MultiQuery is that you have to retrieve the results with an index, based on the order in which you added the criteria or queries. Using index values in your code often reduces readability, so if i can i try to avoid using them.

So i wrote a little QueryBatcher class which allows me to retrieve the results based on a key value. The class supports MultiCriteria as well as MultiQuery so you can use it to batch all kinds of queries. I didn’t find a way to combine the batched criteria and the batched HQL queries in one database call, so if you mix criteria with hql queries, it will use one database call to execute all the criteria, and one database call to execute the hql queries.

And now i can write code like this:

Obviously, this is a very simple example with extremely simple queries… but you can of course batch very complex queries with this as well. You can also add queries that return scalar values so you could for instance do do something like queryBatcher.GetResult<long>(”TotalOutstandingAmount”) and it would return that scalar value.

This is the code of the QueryBatcher class: