In this post, i’d like to take the chance to explain the downsides to exposing entities through services.  Though i’ll probably miss quite a few of the downsides (feel free to add to the list through comments), the ones i will mention are IMO important enough to take note of.

Exposing entities to clients means your clients are very tightly coupled to your service(s)

Entities are a part of your domain.  These entities in your domain can change for various reasons.  Sometimes because functional changes are required, but quite often also for optimizations (whether they are for performance reasons or to improve the clarity and maintainability of your domain).  Functional changes can impact your clients, though that is not necessarily the case.  Optimizations hardly ever have an impact on your clients (other than possibly improved response times from your service calls obviously).  If your service layer accepts and returns domain entities, each possible change is highly likely to have an impact on your clients.  And this impact is not cheap.  In the best case scenario, it means updating your service contracts, regenerating your service proxies and redeploying your clients.  In the worst case scenario, it means making actual changes to the code of your clients.  And for what? Because of changes that shouldn’t have impacted your clients in the first place?

Ideally, your clients are as dumb as they can be.  They should know as little as possible about the actual implementation of the domain because that implementation is simply not relevant to them.  They should present users with data and give them the option to modify that data, to trigger actions and to perform certain tasks.  They should focus squarely on those tasks and pretty much everything else is typically better suited to be done behind your service layer.  If you build your clients with no real knowledge of the actual domain model, but of DTO’s and possible actions to be performed then you can reduce the level of coupling between your clients and your services substantially.

Many of the people who prefer to expose entities often claim that going for the DTO approach introduces too much extra work and too many extra, seemingly unnecessary classes.  For starters, they don’t want to write code that maps entities to DTO’s.  First of all, the amount of code that this requires is in reality very small, not to mention very easy.  Secondly, you can just as well use a library such as AutoMapper to take that pain away from you.  And contrary to what you might think, there is a big performance gain to be had from returning DTO’s over entities, but i’ll get to that in the next section.

Entities are hardly ever the most optimal representation of data

I think we can safely say that most applications need to show data in the following 3 ways:

• In a grid view, either as a total listing of all instances of a certain type of data or the result of a search query or some kind of filtering action
• In dropdown controls or anything else that lets users select pieces of data
• In edit screens where a piece of data needs to be displayed in its entirety, perhaps even to be modified by the user

There are undoubtedly more ways in which data can be presented to the user but i think it’s safe to say that most business applications will certainly rely on the following 3 ways quite heavily.

In the case of a grid view, you’re frequently showing data that is related to more than one entity.  You’ll often need to include the name or the description of some associated entities.  So what exactly is it that you want to do in this situation?  Do you want to return a list of the main entities of the grid view, which all have their required association properties filled in so you can display the columns that you need in the grid view?  Do you actually need all of the properties of these entities (for both the main entities and the associated entities)?  Odds are high that you’re going to be returning a lot more data to the client than you actually need.  And that is what is realistically going to hurt the performance of your system.  Any piece of unnecessary data that you transmit to your clients has a cost associated with it.  The unnecessary data is retrieved from the database.  The entities are then serialized at the service end.  Then they are transmitted to the client.  Then they are deserialized by your client.  All of this is pretty costly, so the more unnecessary data that is included in this operation, the more your performance and the responsiveness of your client (not to mention your database and your server) is impacted negatively.

In the case of dropdown controls or anything else that lets users select pieces of data, you typically only need very few of the properties of that piece of data.  In many cases, the primary key and a name or a description are sufficient.  Do you really need to transmit the entire entity every time for usages like this? Again, keep in mind that all of that extra data that will never be used by your client needs to be retrieved, serialized, transmitted and deserialized again.  Surely, this is an awful waste, no? 

And then there’s the case where a piece of data needs to be displayed in its entirety.  In these cases, you will almost always need all of the properties of the entity that is displayed, but you’ll most often also need to show other data (things that can be selected, or linked to the main entity).  This other data will in most cases fall into the previous category where you’ll only need very little information about the actual entity.  If you’re smart, you’ve chosen the DTO approach to retrieve this data for the data that can be selected, and in that case, you already have all of the infrastructural code in place to project entities or data into DTO’s.  So you might as well reuse it for the main entity as well since you already have the capability to do this.

Always keep in mind that your entities will frequently either contain more data than needed, or less data than needed.  As such, it just doesn’t make much sense to expose entities to your clients since they are hardly ever optimal for client-side usage.  If you really want to think about performance, stop worrying about the supposed cost of mapping to DTO’s (which is truly negligible) and start focusing on what your actually sending to and from your service because this is far more costly than any kind of DTO-mapping really is.

Must your data really come from entities?

If you are displaying data to your user, does that data really need to come from your domain model?  Does it really need to be retrieved by populating a collection of entities to then return them to the client?  Again, keep the form of the data in mind when thinking about this.  In many cases, as i mentioned above, an entity is not the most optimal form of the data that your client needs.  So why even retrieve it through entities? Sure, asking your ORM to retrieve a set of entities based on a set of criteria is often the easiest thing to do, but if the easiest path were the best path, the overall quality of software projects wouldn’t be in the sad state that it’s in today.  If the form of the required data is not identical to the structure of an entity, it’s often far more optimal to simply populate a DTO directly from the data.  With NHibernate, you can easily do this by adding a list of projections to your query and then using a ResultTransformer to populate the DTO’s based on the direct output of the query.  In this case, no entity instance ever needs to be created when you’re just retrieving data, and no extra mapping between the entity and the DTO’s needs to be performed.  Your data access code simply retrieves the resulting data from a query, and puts that data directly in your DTO’s.  There’s no reason why usage of an ORM should prevent you from doing this.   Once again, this approach will offer far more performance benefits than avoiding DTO mapping at all costs ever can.

What about the behavior of your entities?

Do your entities have any behavior in them?  If not, they are already more of a DTO than a true entity.  In fact, if your entities have no behavior at all, you could even wonder why you’re using an ORM in the first place.  Now, behavior can mean many things.  It could mean lazy loading of associations.  It could mean actual business logic.  Obviously, lazy-loading doesn’t (and shouldn’t!) work client-side, but what about your business logic? Do you have business logic that can be executed client-side? Or is it business logic that should only be executed behind the service layer? If so, how do you make the distinction between this to prevent client-side usage from these entities? Whatever you do, you’re pretty much opening up a can of worms that really is better avoided in the first place.

How are you going to deal with technical issues?

Accepting and returning entities from services introduces a host of technical issues that can be quite substantial.  Serialization and deserialization specifically are issues that you need to be worried about.  If you’re using an ORM which does lazy-loading of associations, this will certainly cause serialization issues that you need to work around.  You can either disable lazy loading, or you can make sure that your entities are always fully initialized (as in: always have their associations fully loaded) before they are sent back to the client.  Disabling lazy-loading will cause performance problems in your service layer, either in places where you don’t expect them to be or in places that you haven’t thought of before it’s too late.  Fully loading your entities and their associates before returning them is another performance nightmare waiting to happen so that’s really not an ideal solution either.  You can try to hook into the serialization process or even the lazy-loading features of your ORM but whatever you do in that case will be a hack that will cause issues sooner or later.  And again, all of these problems can very easily be avoided with a solution which, i hope you realize by now, offers plenty more benefits than any solution where you accept/return entities in your service.

Conclusion

Every single downside to exposing entities through services are issues that i have myself encountered in past projects, either ones i’ve worked on myself, or ones that i’ve seen other people work on.  If that’s not enough for you, then maybe you’ll find it interesting to know that some of the brightest and most respected people (like Udi Dahan and Ayende for instance) in the .NET community also actively recommend against exposing entities through services because of the same downsides that i mentioned, though they could probably give you even more downsides that i forgot to cover in this post.  These downsides are not figments of anyone’s imagination.  They are very real, and you really, really ought to think twice before dismissing this advice. 

First, i’ll show the whole class again:

Basically, the purpose of this class is to hold a set of ISessionFactory instances, each of which belongs to a particular tenant in a multi-tenant application.  Tenants can be added on the fly (without restarting the application) and when an ISessionFactory doesn’t exist yet for a particular tenant, it must be created when the first request for an ISession for that tenant comes in.  Obviously, access to the sessionFactories dictionary must be thread-safe since multiple threads will be reading from the dictionary as well as occasionally writing to it.

I considered 3 options to make sure access to the dictionary would be thread-safe:

1. Traditional locking (through the lock statement or the Monitor class)
2. Using the ReadWriterLockSlim class
3. Using the copy-on-write pattern

Traditional locking was quickly scratched from the list because that would require me to lock for every read of the dictionary as well as every write.  Now, pretty much every single request requires an NHibernate session which means that pretty much every single request results in a lookup in the sessionFactories dictionary.  If i need to lock for every read, this significantly hurts overall throughput of the system. 

The ReadWriterLockSlim might be a good solution here… after all, the short description of this class in MSDN says this:

Represents a lock that is used to manage access to a resource, allowing multiple threads for reading or exclusive access for writing.

Sounds like what i need, right?  But the thing is, i’ve never used the ReadWriterLockSlim class before and it hasn’t really gained my trust yet.  I know that’s a terrible excuse for not using it, but here me out.  While the ReadWriterLockSlim likely reduces locking overhead over traditional locking substantially, there still has to be some overhead for read operations, even if it is small.  In most situations, that small overhead wouldn’t bother me but in this case, that little overhead would be added to pretty much every single request in the system.  Now, writing to a dictionary implies that a new tenant has been added to the system.  In the context of this system, that’s not even gonna happen on a daily basis.  Hell, once a week is probably a best-case estimation and even that is highly optimistic.  So i really don’t want any kind of overhead on read operations when the write operation is only going to happen very occasionally.

That leaves the copy-on-write pattern.  I’ve used it before with success (though at the time, i didn’t know it was a known pattern) so this approach has already gained my trust.  It basically implies that we don’t do any locking on the read operations, but whenever a write operation occurs we copy the original set of objects, perform the write on the newly copied set and then set the reference of the original set to the newly created and modified instance.  During this whole time, every single read is safe.  Successive reads within the same logical operation however aren’t, so the following code would not be thread-safe:

Because there’s no locking on the reads, the code within the if-block could fail because the sessionFactories reference could be pointing to a new dictionary which no longer contains the element for that key. 

Of course, if you have frequent writes, the overhead of copying the set of objects every time you need to add/remove one might be bigger than you want, so this isn’t a pattern that you should use whenever you need to protect access to a shared resource. For this situation however, i think it’s ideal… though i’d obviously like to hear about better solutions

Now, let’s take a closer look at the pieces of code that perform the write operations.  First, adding a new ISessionFactory to the dictionary:

As you can see, the entire operation is put between a lock on the writeLock object instance.  The downside of this is that creating an ISessionFactory instance is an expensive operation, which means the lock will be held for a long time (could easily be one or more seconds).  Then again, i don’t anticipate this happening frequently so it’s not that big of an issue… especially since reads aren’t being blocked by this anyway.  This approach also prevents the creation of 2 ISessionFactory instances for the same tenant.  Well, unless i missed a bug here :p

Now, once the ISessionFactory instance is created, we create a new Dictionary based on the contents of the old one and then we add the new ISessionFactory instance to it.  After that, we replace the sessionFactories references with the new dictionary and from that point on, every read will use the new dictionary instance.  During this entire operation, no read operation was impacted negatively. 

Now lets take a look at the other write operation, removing an ISessionFactory instance from the dictionary:

The first if-check, which happens outside of the lock is a bug that i missed but that was pointed out in the comments of the original post.  If CreateSessionFactoryForCurrentTenant and RemoveSessionFactoryForTenant would execute concurrently for the same tenant, it’s possible that the ISessionFactory instance of that tenant is never removed from the dictionary (and also never disposed of…) since the check happens outside of the lock and could be executed before the ISessionFactory of the tenant was added to the dictionary.  In that case, the ISessionFactory instance would stay in the dictionary as long as the application stays up.  This is definitely a race condition that you want to avoid in every other situation though in this case, the odds that we’re simultaneously adding and removing the same tenant are slim to none.  Nevertheless, i don’t want to be accused of promoting race conditions so we’ll make the change anyway

Now, as you can see we once again create a new dictionary based on the previous one, then remove the ISessionFactory instance for the current tenant and then we overwrite the sessionFactories instance once again.

Finally, there’s the read operation that i specifically didn’t want suffering from locking overhead:

The only time this code will block is when a new ISessionFactory for the current tenant needs to be created.  Luckily, that only happens once for each tenant.  As i mentioned earlier in the post, using this pattern doesn’t guarantee that successive reads within the same logical operation are thread safe, so there is a bug in here.  If a tenant already has an ISessionFactory instance, it’s possible that the RemoveSessionFactoryForTenant method has been executed between the if-check and accessing the ISessionFactory based on the tenantId.  In that particular scenario, the ISessionFactory instance is no longer in the dictionary which will cause this code to throw an exception.

That’s a bug that i don’t feel like fixing though… Once a tenant has been removed, they are no longer a paying customer.  If they are no longer paying for the software, there is no reason whatsoever why i should care about any possible exceptions they could get while running the software

Seriously though, if the RemoveSessionFactoryForTenant method is called, users of that tenant won’t even have access to the system anymore so it’s really a non-issue.

Anyways, i think i’ve covered the implementation in more detail than you probably cared for.  So, any thoughts? Are there still issues that i haven’t thought of? Is there another approach that you would use for this specific scenario?

Is it really that much more expensive though? I ran a little experiment and i’d like to share the results with you.

Suppose you have the following 2 classes:

As you can see, there is no difference between the IncreaseLong and VirtualIncreaseLong methods, except that the latter is virtual and the former is a regular instance method.  According to many people, calling VirtualIncreaseLong instead of IncreaseLong will be more expensive.  I also have a derived class which overrides the VirtualIncreaseLong method with a slightly different implementation.

If we call these methods a bunch of times (like 1000000000 times), we should notice quite a difference according to many people.

I wrote the following test code which calls these methods a bunch of times, times it, and outputs the results.

The output of running this code might surprise you.  On my machine, i got the following results when the code was compiled in debug mode:

The difference between calling the regular instance method and the virtual method is quite small.  I’d even say it’s negligible.

When compiling in release mode, i got the following output:

I ran the test a bunch of times, and there was no consistent observable performance penalty when calling the virtual methods.  In fact, the virtual methods often performed faster than the regular instance methods and in most cases were equally fast.  I’m not claiming that virtual methods are faster than regular instance methods, but if there really was an extra real-world performance cost associated with virtual methods, it surely should be observable with this test code, no?

Obviously, this test isn’t scientific in any way.  But still, i think it does show that the so called performance cost associated with virtual methods is highly overrated.  There definitely will be cases where virtual methods are more expensive than regular instance methods, but i’m willing to bet that those cases are rare and that the vast majority of .NET developers will never be negatively impacted by it. 

Side note: have you ever noticed that most people who recommend to avoid virtual methods due to their performance cost never put the same emphasis on avoiding the cost of say, frequent remote operations?  Which is odd, since i wouldn’t be surprised if that would be the most common reason for performance problems with .NET applications.  Then again, that’s what you get when the biggest company pushing a platform advocates meaningless performance improvements while at the same time pushing bad architectural decisions/guidelines on the world because the resulting code is supposedly easier to write, use and maintain.

You can download the example code here so you can run the test yourself. 

And here’s a simplified version of the Process method:

The part that is simplified is simply the part that deals with getting the actual responses for each request, including how to deal with failed requests and how to handle subsequent requests in the batch. It’s not relevant to this post and it only clutters the code more so i left that out. But anyways, the interesting part here is the performance logging. Ok, the code itself isn’t interesting but what you get out of it is pretty nice. Each single request that takes more than 100 milliseconds is logged. Also, each batch of requests that takes more than 200 milliseconds is logged. Both of these ‘events’ are logged to the performance logger which, in our case, is set up to use a different logfile than the typical error log.

Which gives us some interesting looking data, like this:


WARN 2009-09-05 08:58:45 - Performance warning: 122ms for GetOpportunityCardHandler
WARN 2009-09-05 09:00:45 - Performance warning: 159ms for GetCompanyCardHandler
WARN 2009-09-05 09:01:23 - Performance warning: 187ms for GetOpportunityCardHandler
WARN 2009-09-05 09:01:32 - Performance warning: 155ms for GetCompanyCardHandler
WARN 2009-09-05 09:01:41 - Performance warning: 189ms for GetOpportunityCardHandler
WARN 2009-09-05 09:01:41 - Performance warning: 336ms for the following batch: GetSalesTaskCardRequest, GetContactCardRequest, GetOpportunityCardRequest, GetCompanyCardRequest


336ms for a single batch of requests is rather slow, and if we see this output regularly in the logfile, we definitely know that these specific request handlers really need to be optimized because we can be pretty sure that is too slow in the real production environment.

It’s also useful to identify single request handlers who could use some optimization:


WARN 2009-09-04 02:55:40 - Performance warning: 108ms for PersistIssueHandler
WARN 2009-09-04 05:54:50 - Performance warning: 148ms for PersistTimesheetEntryHandler


We’ve already deployed this for an internal version of one of our applications, which helped us identify some parts that we really needed to optimize before our next external deployment (for our customers). Even better, when we deploy for our customers, each log entry will also contain the name of the tenant (customer) for which the performance warning was generated. Which will only make it easier for us to identify real hotspots, based on real usage from our customers, and try to optimize them as soon as possible, preferably before customers start complaining about specific parts.

I’m sure some of you are already doing something similar, but i’m also pretty sure that most of you aren’t doing this yet. I’d definitely recommend doing something like this, because it definitely makes it easier to fix _real_ performance issues instead of the theoretical ones

First of all, ViewState is persisted in the resulting HTML page through an IStateFormatter object. We’ll provide our own CompressedStateFormatter which implements the IStateFormatter interface, and uses the standard IStateFormatter that ASP.NET uses:

The idea is very simple: when the Serialize method is called, we first call the real formatter’s Serialize method, compress its return value and then return the Base64-encoded string of the compressed serialized state. And in the Deserialize method, we do the exact opposite: we first decompress the Base64-encoded string and then we use the real formatter to deserialize the actual ViewState.

In Mamanze’s example, he checks to see if the compressed version is actually smaller than the decompressed version and if so, uses the decompressed version instead of the compressed one. And when decompressing he first checks to see if it’s a compressed or decompressed version and obviously only decompresses in case of a compressed version. The only page where i found the compressed version of the ViewState to be larger than the decompressed version was in our log in page, so i just got rid of that piece of the code.

Now we still have to plug this into ASP.NET’s behavior somehow… first we add a pagestate.browser file to the App_Browsers folder of your web application (if it doesn’t exist, just create it) with the following content:

The CompressedPageStateAdapter looks like this:

And the CompressedHiddenFieldPageStatePersister class looks like this:

The HiddenFieldPageStatePersister is the class that ASP.NET WebForms will use by default to store your ViewState into a hidden field in the resulting HTML. By default, the HiddenFieldPageStatePersister uses the default IStateFormatter type that ASP.NET uses, which only uses Base64 encoding but no compression. Unfortunately, there is no clean way to instruct ASP.NET to use a different implementation for IStateFormatter, so we need to use a bit of reflection to overwrite the value of HiddenFieldPageStatePersister’s _stateFormatter field. Luckily, this also enables us to first get the value of the StateFormatter property so we can pass this reference (which is the ‘real’ formatter) to our CompressedStateFormatter.

And that is all there is to it… all of your pages will now use this CompressedHiddenFieldPageStatePersister so you get the benefit of ViewState compression in each of your pages. You can also do this selectively if you want, by not using the pagestate.browser file and overriding the PageStatePersister property of your ASPX page:

This way, only the pages that contain this code will use the CompressedHiddenFieldPageStatePersister.

Instead of inheriting from HiddenFieldPageStatePersister, you could also inherit from SessionPageStatePersister. SessionPageStatePersister will store your ViewState in the HttpSessionState, and will only include a little bit of ViewState in your HTML page instead of everything. But you do need to be aware of the fact that using the CompressedStateFormatter when inheriting from SessionPageStatePersister will only result in compressing the little bit of ViewState that is included in the HTML, and not the ViewState that is stored in the HttpSessionState.

In case you’re wondering: why should i use this instead of using typical HTTP compression on the IIS level? I believe it has a couple of advantages to HTTP compression. First of all, AFAIK, HTTP compression does not have any benefit on postbacks. And since ViewState is always posted back to the server, this can make a pretty big difference. Also, with this approach, the client will not have to decompress the entire ViewState (which isn’t used client-side anyway) and the browser doesn’t have to waste time on it in general.

I haven’t used this in production yet, but i will very soon… unless someone knows of a good reason why i shouldn’t

For some reason, a lot of people seem to think that opening an NHibernate session and performing thousands of operations is a valid use case. It’s not. Far from it actually. And with all of the features that NHibernate offers, it can’t possibly perform well in such a scenario. See, an NHibernate session is a unit of work. A unit of work is a business transaction which is typically short and small, but it should never be something huge. Your DBA probably won’t appreciate huge database transactions on the database either.

Whenever you load an object through NHibernate, it will be tracked by the session that loaded it. That means that the NHibernate session keeps a reference to it, and performs a series of checks on it periodically, depending on what you’re doing and some configuration settings such as the FlushMode. For instance, suppose you’ve loaded a hundred different entities in one session. If the FlushMode is set to automatic, it means that NHibernate will perform a dirty check for each entity associated with the session before each query is executed. The more entity instances you’ve loaded, the longer this takes (obviously). If you take this to an extreme level, like loading thousands of entities like most of these ‘benchmarks’ do, performance will naturally be horrible.

Each entity instance is also stored in the first level (or session level) cache. That means that whenever you retrieve a row from the database, NHibernate will check if an instance of that row already exists in the first level cache. Again, the more instances you’ve loaded, the larger the overhead of this will be. There are also a lot of possible extension points where you can plug in custom logic. Again, there is a very minor cost that comes with this extensibility and as you can expect, that minor cost can add up to something much more noticable once you start dealing with an unreasonably large number of instances in your session.

Always keep in mind that an ORM (and this goes for every ORM) is most suitable for OLTP. Using an ORM for batch processing jobs or large data processing operations in general is simply put a bad idea. And they will never perform as well as other solutions in these scenarios. So please don’t bother even benchmarking ORM performance in non OLTP usage because it quite simply doesn’t make sense to do so, and the results will be completely untrustworthy anyway.

An ORM can offer you nice performance gains in OLTP scenarios simply by trying to minimize database connectivity, minimizing the number of database operations, and relatively sane caching usage. Unfortunately, these are aspects that are never tested in these ‘benchmarks’ or ‘comparisons’.

I logged into the buildserver and ran the tests manually using nunit’s console runner (with an NUnit-2.4.7 build that i happened to have installed somewhere on the machine) and they only took about 45 seconds. After a lot of guesswork and screwing around, it turned out that we never modified our base build script (why yes, i do believe in build script inheritance) to use a newer version of NUnit. We set up the buildserver about 1 year ago, and at that time, the latest stable NUnit version that TeamCity supported was NUnit 2.4.6. Our base build script was still referring to NUnit 2.4.6, which apparently sets log4net to use debug level logging. Now, NHibernate logs a huge amount of information at the debug level, so this turned out to slow down all of our builds that had NHibernate tests.

We changed the the 2.4.6 version in our script to 2.4.7 and the build time of this particular project decreased from around 50 minutes to about 35 minutes. Yes, that’s still a lot but this is a huge project with a lot of legacy tests and the entire build process is pretty complex. Other projects went from build times from around 7 minutes to about 2 minutes.

That’s a pretty nice improvement for simply changing a “6″ to a “7″

We tracked down the query that was causing the bad performance and ran it on the database of Tenant B. Tenant B actually had a lot more data in the main table that was used in the query and the query executed immediately whereas it took about 25 seconds to complete for Tenant A. So the query runs fast on another database that actually has more data… at this point i was convinced that it had to be related to indexes.

Turns out that someone recently ran an import process to import a bunch of data in Tenant A’s database. I know very little about databases, but one thing i’ve seen time and time again (with both Oracle and SQL Server) is that you really need to make sure that your indexes are in good shape after any process that performs a lot of inserts (or removals). A couple of years ago, i had a very intensive nightly import process for a particular project that used an Oracle database. As time went on, the application’s queries became painfully (unacceptably even) slow. I managed to restore the performance of those queries by simply instructing Oracle to recalculate all of the statistics of the indexes of tables that were affected heavily during the nightly import.

With that in mind, we simply rebuilt the indexes for Tenant A’s database, and the same query that took 25 seconds completed almost instantly from then on. Now, we did had a weekly job running on that database server to keep the indexes in a healthy shape but that job didn’t really do a good umm… job of it, apparently.

Lessons learned: make sure that you:

• Have a proper maintenance job set up which keeps your indexes healthy and schedule it to run regularly
• Run that job manually if you need to perform a manual import process
• Execute that job in an automated fashion whenever an intensive automated import process has completed

Oh, and consult with your DBA’s or at least people who know what they’re doing when it comes to your particular database on how to keep those indexes healthy. In this case, we rebuilt them. In other cases it’s sufficient to recalculate the statistics… i’m not sure which way is the best but you should at least keep an eye on this possible problem

If you want to learn how the guid.comb strategy really works, be sure to check out Jimmy Nilsson’s article on it. Basically, this strategy generates sequential guids which solves the fragmented index issue. You can generate these sequential guids in your database, but the downside of that is that your ORM would still need to insert each record seperately and fetch the generated primary key value each time. NHibernate includes the guid.comb strategy which will generate the sequential guids before actually inserting the records in your database.

This obviously has some great benefits:

• you don’t have to hit the database immediately whenever a record needs to be inserted
• you don’t need to retrieve a generated primary key value when a record was inserted
• you can batch your insert statements

Let’s see how we can use this with NHibernate. First of all, you need to map the identifier of your entity like this:

And that’s actually all you have to do. You don’t have to assign the primary key values or anything like that. You don’t need to worry about them at all.

Take a look at the following test:

Interesting, no? The entities have an ID value after they have been ‘saved’ by NHibernate. But they haven’t actually been saved to the database yet though. NHibernate always tries to wait as long as possible to hit the database, and in this case it only needs to hit the database when the transaction is committed. If you’ve enabled batching of DML statements, you could severly reduce the number of times you need to hit the database in this scenario.

And in case you’re wondering, the generated guids look like this:

81cdb935-d371-4285-9dcb-9bdb0122f25f
a44baf99-58e9-4ad7-9a59-9bdb0122f25f
a88300c2-6d64-4ae3-a55b-9bdb0122f25f
032c7884-da2f-4568-b505-9bdb0122f25f
….
70d7713c-b38d-4341-953d-9bdb0122f25f

Notice the last part of the guids… this is what prevents the index fragmentation.

Obviously, this particular test is not a realistic scenario but i’m sure you understand how much of an improvement this identifier strategy could provide throughout an entire application. The only downside (IMO) is that guid’s aren’t really human readable so if that is important to you, you should probably look into other identifier strategies. The HiLo strategy would be particularly interesting in that case, but we’ll cover that in a later post

The following code simulates the issue:

The only difference between both Add operations is that in the first case, the typed Add method of the generically typed List reference is called. In the second case, the untyped Add method of the generically typed List is called through the IList reference.

On my slow Macbook, the first Add operation typically took between 10 and 20 ms. The second Add operation typically took almost twice as long as the first Add operation. As you can see, that is a very minor performance issue, and it actually is only consistently noticeable once you’re dealing with 100000 elements. At 50000 elements, both operations typically take the same amount of time with only minor variations in performance on certain runs.

So yes, once you’re dealing with a large enough set of elements, there is indeed a performance difference. But it’s extremely minor and the extra cost of the Add operation is most definitely the least of your concerns if you’re retrieving that many entity instances through an ORM. The extra amount of memory that needs to be used for those entities and the extra cost of pulling all of that data over the wire is what’s really going to bite you, not the extra cost of the Add operation

Two of the FindAll methods now look like this:

The only thing i changed in those methods is calling the Future method, instead of the List method. That’s it. All of our specific Find-methods (those that execute specific queries) pass through the FindAll(DetachedCriteria criteria) method so they all benefit from this change.

That means that all of our queries are suddenly batched transparently whenever possible, without impacting any of the calling code. And that is pretty nice if you ask me. Batching queries can offer a substantial performance benefit, and we didn’t even have to change any of the calling code to achieve it.

Obviously, this only works for the queries that return IEnumerables (in our case, that’s every query that doesn’t return a single value). I also added a few more methods to enable query batching for queries that return a single entity, or a scalar value (i kept the original methods in this code snippet as well so you can see the difference):

So let’s recap. Queries that return IEnumerables are all batched transparently whenever it’s possible to do so. No calling code had to be modified to get this benefit. Queries that return single values (an entity instance or a scalar value) that still use the ‘old’ FindOne, GetScalar and Count methods obviously couldn’t benefit from the transparent batching without breaking backwards compatibility, but the new methods that were introduced do enable transparent batching for these queries from now on.

Does all of this sound too good to be true? I’d be skeptic too if i were you but i made these changes a few months ago actually and we have been using this stuff on a couple of projects with zero problems.

Obviously, you need NHibernate 2.1 Alpha 1 (or later) for this or the current trunk, both of which i would recommend over NH 2.0 at this point.

Below is a list of rules of thumb that i always try to keep in mind. Keep in mind that these are just rules of thumb… they are not rules that never should be broken, nor are they applicable to each and every situation. In general though, i do believe that if you keep these in mind you can avoid serious performance issues and the need to do heavy architectural refactoring in the long run. So without further ado, these are the performance-related things that i do care about while i’m writing my code:

• Be careful with anything that goes out of process (web/wcf service calls, database calls, external systems/components, …). The cost of these calls is often higher than you’d imagine and might not become noticeable until the load on your system increases, or when you start executing these calls in long loops.
• Fetch your data in a smart manner… Never retrieve data in a loop, but retrieve it outside of the loop in a more coarse-grained manner. Sometimes it makes sense to use some joins to retrieve data, but in other cases you’re better off with executing separate queries to avoid retrieving large Cartesian products. If your data layer implements caching in some way, use it in a smart manner
• Dispose objects that need it as soon as possible… Not doing this could lead to costly dangling resources and/or memory leaks… if this eventually leads to swapping/paging you end up with abysmal performance
• Don’t transfer more data than you need to. Whether you’re sending data over a service or you’re pushing HTML to a browser, your total bandwidth and/or the client’s download speed is usually limited so this could lead to slowdowns that you can often avoid. Note that i don’t recommend making everything as compact as possible, but a little bit of common sense can go a long way here.
• Don’t go crazy with multi-threading and asynchronous operations. While these can generally help a lot when it comes to responsiveness (and thus, the perceived ‘slowness’ of your application) they aren’t always the perfect solution. I once saw an ‘architect’ run a data import process (which had to insert that data in a remote database) over 64 threads, because it was too slow in one thread. He was surprised to see that his 64-thread solution wasn’t faster than his single-threaded version. I wasn’t surprised at all… I suggested getting rid of the multi-threading and to batch the insert statements, which improved the situation greatly.
• Don’t hold on to large sets of data for too long. A large set of data could be a lot of database records, but it could just as well be a lot of strings, or just other objects in general. Keeping these in memory for a long time prevents them from being garbage collected as soon as they can be, which can greatly increase memory pressure in your system. Be especially careful with long-running loops that iterate over large sets of data. If you no longer need the data after you’ve left the loop, you’re often better off getting rid of each item in the set as you’re done processing it.

And that’s pretty much it… outside of the stuff listed above, i typically don’t care about performance. I try to keep my code clean and focused, and rely on profiling to identify performance hotspots. When the profiler identifies problems, they are often more easy to solve if you’ve kept your code clean than it would be if you had tried to prematurely optimize in the wrong places.

Those of you who’ve been reading this blog for a while know that i’ve often stressed the importance of reducing the number of remote calls. Yeah that’s right, i just linked to 7 of my own posts in a single sentence :p

Anyways, there were a few people who thought that my preference for batching queries/service calls was actually a case of premature optimization, and that it was therefor evil and not something you should be doing until it was actually necessary to do so. The speaker of the presentation explained that there is a difference between premature optimization and pro-active performance management. Performance and scalability simply do not come for free, and you have to keep certain things in mind if you want your system to have those qualities.

Now, before i go further, i would like to state that i do believe that clean, simple and reusable code is something that developers should always strive for. I also believe that you should try to limit the number of times you hit the database, or the number of remote service calls you make in a single business transaction. Those goals often seem to contradict each other. There aren’t too many data access layers that allow you to easily perform multiple queries in a single roundtrip while still making sure that each query is reusable in a different context. It gets even worse when it comes to remote services. As you undoubtedly know, a lot of industry experts will recommend that you provide coarse-grained service interfaces instead of fine-grained service interfaces. The upside of coarse-grained interfaces is that they often offer better performance due to less chattiness in communication. Unfortunately, it also often also leads to services that are implicitly coupled against the clients that are known to be using them. With that i mean that many of those coarse-grained services are designed with certain client-characteristics in mind. And shouldn’t services be independent of the clients that use them? This approach typically has an impact on the reusability of those services for clients which are to be developed after the service has already been deployed.

So how do we solve these issues? It’s pretty simple. I want each database query to be reusable in whatever way i need: combined with other queries in a single roundtrip, or executed separately. I also want a fine-grained service interface where i can execute precisely the ‘remote action’ i need, and avoid the chattiness when i need to execute several of those ‘remote actions’ in a single business transaction. The answer is of course: batching of remote operations, whether they are database queries or remote service calls or whatever else that essentially boils down to an out-of-process call.

I really think that every kind of architecture should at least make this reasonably easy to do so. It really doesn’t take that much effort (or in some cases i’d even call it imagination) to make all of this possible. I’m actually pretty lazy so if i can manage to get it done, there’s no reason in the world why you shouldn’t. It can be done pretty easily, and it really doesn’t come with that much of a cost. Of course, writing your code this way takes a little bit more work than doing it the ‘easy way’ (little more being ‘minutes’ vs ‘hours’ though). But then again, if the ‘easy way’ were the right way, we wouldn’t even be talking about performance anti-patterns, right?

For me personally, i’ve gotten to the point where i really couldn’t care less about possibly slow performing code in advance, as long as that code is executed in-process. No matter how good you are, you will practically always guess wrong when it comes to slow-performing in-process code. Just write clean and readable code and if some parts of it turn out to be slow, you just use a profiler and it will quickly tell you which parts are causing the slowdowns. It’s pretty much always the last place you suspect so why bother writing difficult code for parts that probably weren’t going to be a problem anyway. But for out-of-process stuff: be vigilant, because any performance problem related to it could have easily been avoided from the start.

The code is old, pre .NET 2.0. But no, the usage of the ArrayList isn’t what bothers me here. It first gets all of the Id values for all of the employees in the database. Then it loops through the list of Id values, and fetches each employee from the database. Whenever i see this kind of code, it makes me want to kick the person who wrote it.

In case you don’t know what is so bad about this, think about this: if you have 5 employees you first send one select statement to the database to get their id values. Then you send another 5 select statements to the database to get the data of each employee. Oh well, 6 queries isn’t that big of a deal right? It sure as hell is if you could’ve just as easily gotten all of the required data with one query (and only one expensive roundtrip)! Imagine you have to calculate the paychecks of 100 employees instead of 5. How about 1000 employees?

What i really don’t understand about this is that this kind of code gets written every day. Do these people simply don’t care or do they genuinely not know how bad this is? If they don’t know, that’s truly sad. If they don’t care, that’s even worse because a developer who knows how bad this is but still writes it, obviously takes no pride at all in his/her work and (IMO) has little respect for the code, the team, the company and the client.

In case you’re wondering where i saw this code… it’s in Robert C. Martin’s Agile Principles, Patterns, and Practices in C# book. Yes, the Robert C. Martin, aka Uncle Bob. I probably shouldn’t criticize such a well known figure in the OO world, but seriously Bob, what were you smoking? The purpose of the whole book is to teach people how to write good code and there is tremendous amount of valuable information in there. But putting code like this in your examples is really inexcusable.

First of all, let’s get back to our test code from the last post:

The only thing that changed since the previous post is the amount of objects that are created. In the previous post we only created 10000 objects, whereas now we’ll be creating 500000 objects.

The batch size is configured like this:

This means that NHibernate will send its DML statements in batches of 100 statements instead of sending all of them one by one. The above code runs in 2 minutes and 24 seconds with a batch size of 100.

However, if we use NHibernate’s IStatelessionSession instead of a regular ISession, we can get some nice improvements. First of all, here’s the code to use the IStatelessSession:

As you can see, apart from the usage of the IStatelessSession instead of the regular ISession, this is pretty much the same code.

With a batch-size of 100, this code creates and inserts the 500000 records in 1 minute and 26 seconds. While not a spectacular improvement, it’s definitely a nice improvement in duration.

The biggest difference however is in memory usage while the code is running. A regular NHibernate ISession keeps a lot of data in its first-level cache (this enables a lot of the NHibernate magical goodies). The IStatelessSession however, does no such thing. It does no caching whatsoever and it also doesn’t fire all of the events that you could usually plug into. This is strictly meant to be used for bulk data operations.

To give you an idea on the difference in memory usage, here are the memory statistics (captured by Process Explorer) after running the original code (with the ISession instance):

And here are the memory statistics after running the modified code (with the IStatelessSession instance):

Quite a difference for what is essentially the same operation. We could even improve on this because the code in its current form keeps all of the object instances in its own collection, preventing them from being garbage collected after they have been inserted in the database. But i think this already demonstrates the value in using the IStatelessSession if you need to perform bulk operations.

Obviously, this will never perform as well as a bulk data operation that directly uses low-level ADO.NET code. But if you already have the NHibernate mappings and infrastructure set up, implementing those bulk operations could be cheaper while still being ‘fast enough’ for most situations.

I have an ‘entity’ with the following mapping:

Nothing special here, just a Guid Id field and a string Description field.

First, let’s see how much time it takes to create 10000 records of this without using the batching feature. I use the following method to create a bunch of dummy objects:

Then, the code to persist these objects:

Without enabling the batching, this code took 23 seconds to run on my cheap MacBook. Now let’s enable the batching in the hibernate.cfg.xml file:

A batch size of 5 is still very small, but for this test it means that it only has to do 2000 trips to the database instead of the original 10000. The code above now runs in 5.5 seconds. Setting the batch size to 100 made it run in 1.8 seconds. Going from 23 to 1.8 seconds with a small configuration change is a pretty nice improvement with very little effort. Obviously, these aren’t real benchmarks so your results may vary but i think it does show that you can easily get some performance benefits from it.

You can get performance benefits like this whenever you need to create/update/delete a bunch of records simply by enabling this setting. Keep in mind that this batching of statements doesn’t apply to select queries… for that you need to use NHibernate’s MultiCriteria or MultiQuery features

Another thing to keep in mind is that for this test i used the ‘assigned’ Id generator… which means that the developer is responsible for providing the Id value for new objects. One of the consequences of this is that NHibernate does not have to go to the database to retrieve the Id values like it would have to do if you were using (for instance) Identity Id values. If you were using the Identity Id generator, this configuration setting would have no effect whatsoever for inserts, although the benefits would still apply to update and delete statements.

Note that this approach is good for regular applications, but it’s still not good enough if you need to process very large data sets (like import processes and things of that nature). Obviously, an ORM isn’t well suited for those purposes, but we will examine another NHibernate feature in a future post which makes it possible to use NHibernate in such bulk operations with a pretty low performance overhead.

So naturally, i came up with the SelectCommandBatcher class (i know, i really need to come up with better names). It’s very similar in usage to the QueryBatcher for NHibernate. Obviously, there is one important difference: NHibernate takes care of transforming the database result into entity objects automagically. For the SelectCommandBatcher, you either have to provide some functionality that takes care of mapping the database results to objects, or you can access the results through DataTables (yikes!).

Let’s just get straight to the code, shall we? For the first couple of examples, i’ll focus specifically on how you can retrieve your results so each example only uses one command. At the end of the examples, there is of course one example that illustrates how you can add multiple SqlCommands and fetch the results in one roundtrip (which is after all the purpose of the SelectCommandBatcher class).

Suppose you have some code that is able to transform the content of a DataTable (or a DataRow) to a List of entities (or one entity):

Obviously, this simply returns a new Product for each DataRow in the DataTable. If this were real code, you’d have to put the data of the DataRow into the Product instance. Feel free to consider me lazy

With the SelectCommandBatcher, you can now do this:

Notice how the TransformTableToListOfProducts method is passed to the GetEnumerableResult method as a parameter. How does it work? It’s pretty simple really: The GetEnumerableResult method’s definition looks like this:

Basically, this method requires you to provide a delegate which accepts a DataTable as its sole incoming parameter, and returns an IEnumerable of T with T being any Type your code transforms the result to.

What if your Data Access Layer only has methods to transform individual rows to entities? No problem:

This code uses an overload of the GetEnumerableResult method that looks like this:

You just need to pass a delegate which takes a DataRow as its sole incoming parameter, and returns an instance of T with T being any Type your code transforms the result to. The delegate that gets passed in will be called for every DataRow in the DataTable which contains the results of that specific select command.

Or if your query only returns a single row, you can do this:

Scalar values you say? How about this:

Or if you’re old-school (sorry, couldn’t resist) and just want the DataTable, you can use this:

And of course, here’s how you can execute multiple select queries in one roundtrip:

The queries are executed as soon as you try to retrieve the first result.

That’s all pretty easy to use right? So how does it work? Here’s the code:

I’ve also added it to my Library, although not yet in the downloadable file. You can find the code in the svn repo though.

People with a lot of straight-up ADO.NET experience probably already know this, but you can simply combine your select statements into one SqlCommand. When you execute that command, you get the results to each of the queries that was in the command. So far, nothing new here. I’m currently using a Data Access Layer at work which creates SqlCommand objects for select queries that you can build up through an API. Obviously, i’d like a way to use each query in whatever way is best for the specific scenario i’m working on. I basically want to be able to execute the SqlCommand objects as a stand-alone query, or in a batch with other queries, without having to modify the code that creates the SqlCommand objects.

So i wrote a SelectCommandCombiner class which allows you to combine multiple SqlCommands into one SqlCommand, while making sure that none of the parameters conflict with each other. Here’s the code:

Now execute the command returned from the CreateCombinedCommand method and you’ll get all of the results in one roundtrip. There are a couple of ways to deal with the results… you could simply use a DataReader to loop through all the rows of all the result sets:

Or you could use a SqlDataAdapter to fill a DataSet:

In a future post, i’ll try to make this as easy to use as the QueryBatcher for NHibernate.

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

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