Once

Configuring Nancy's View Engine

This was infinitely more complex than using a referenced library in a razor view with MVC. Translation: this was as simple as adding a "razor" section to the web.config:

Its worth noting that when I added SquishIt.Framework to the namespaces section it worked, but didn't help with intellisense. So I ended up adding the @using directives in my views anyway. So if you want intellisense, don't bother with the namespaces if redundancy bothers you.

Static Bundles

The typical SquishIt use involves writing a new css or javascript file to the server's file system. At least I think it does - this is certainly what I would consider typical. So I looked at that first. First thing I needed to do was figure out how to get Nancy to render a view for me. It wasn't terribly difficult, just had to set up a module with the routes involved:

By convention, Nancy locates the view in Views/Home. I assume it would look in Views/Shared next, but didn't bother to confirm. So I added couple javascript files in Content/js, and then added a view with a bundle:

As long as I disabled debugging, a single tag was rendered into my page for bundle.js. That was easy.

Cached Bundles

SquishIt also has the ability to render bundles to an internal cache instead of the file system. This is useful for shared hosting environments. You can read the initial documentation here. Getting this to work with Nancy was not really that different - we just needed to create a module to handle serving the assets:

This module renders a cached bundle by name using SquishIt's globally configured MIME types to render the content. It also sets a cache-control header on the response, just because I wanted to see how to set headers with Nancy.

We then need to add a Global.asax and build a bundle:

The second parameter here is called filePath, but actually represents the path to the assets controller, including the "name" parameter. This is what gets used in the src attribute of the rendered tag.

Finally we can add a view. Note that the cached bundle is rendered by name into the page:

and change our HomeModule to serve the route:

Piece of cake.

Conclusion

This was my first exposure to Nancy, and I came away pretty impressed. Its no-nonsense approach reminds me of other projects I've messed around with in the past like manos and ServiceStack. I hope to get a chance to play around with it at least a little bit more.

I'll think about putting together a package to help with integration (similar to SquishIt.Mvc but its so easy to get going that I'm not sure its needed (that package is only a controller and a few extension methods that return MvcHtmlStrings instead of strings). I guess I will have to see if there is any demand, or if there are any issues preventing Nancy from being used in shared hosting environments to see if it'd be worth it.

The sample project can be downloaded in its' entirety at github.

There are some good reasons for this. Why force people to download things like Jurassic or dotLess if they don't have the need? The flipside of this is that we'd been deliberately avoiding adding support for SASS/SCSS because of concerns about linking to IronRuby - these concerns largely disappear when preprocessing becomes an opt-in behavior. Some of these libraries don't even work on Mono (I think .less might be the only one that works currently) so I feel extra bitter downloading code that won't run on my platform of choice. Finally, the growth in adoption has been so fast that frankly, we're unable to keep up.

So let's take a look at some of the original code (well not original as some of our refactorings did find their way to the 0.8.x branch).

As you can see, the trigger for preprocessing is the extension. This is the desired behavior, but the way it was coded left it very brittle and made adding new preprocessors unwieldy. So we set out to find a way to break this code out of the core library.

The approach that we used was plugin based - we defined an interface and exposed a mechanism to register implementations of this interface with the core library. Our original interface actually checked a file name to see if it needed preprocessing, so you could define any logic you wanted to determine whether to preprocess - we ended up eschewing this to go back to the extension-based decisions, for reasons that will be discussed later. The interface looks like this:

The "ValidFor" method does exactly what it says - check if the preprocessor should be used with the supplied extension. "Process" is where the actual preprocessing happens. The array of extensions is exposed publicly to be used in registering the preprocessor - this is because each type of content bundle has a list of allowed extensions that is used to filter what gets included when we add a directory full of files. Finally, the ProcessResult type includes a string representing preprocessed content and a list of any dependent files that were changed. This last part was added by Simon Stevens to enable inclusion of .less imports as dependent files.

Preprocessors can be registered two ways - both statically and with a particular bundle instance. For the instance level configuration there is a method in the bundle's fluent API called "WithPreprocessor" that allows inclusion of a preprocessor with that bundle instance. Globally, we used the static "Bundle" class to allow preprocessor registration - methods exist there for registering script, style, and global preprocessors. If preprocessors of the same type are registered both statically and with a bundle instance, the instance-level preprocessor will be used.

Now, back to why we decided to make preprocessor selection based on extension rather than the complete file name. To understand, I guess all you have to do is read about the Asset Pipeline in Ruby on Rails, but I will attempt to summarize here. The beautiful thing about the pipeline approach is the ability to chain preprocessing steps. This allows you to use ERB's helper methods in your file prior to other preprocessing. For example, if you wanted to use ERB helpers in a coffeescript file you can name your file file.js.coffee.erb - when an asset has the .coffee and .erb extensions, both preprocessors will be applied. The order they are applied is driven by the reverse order of extensions, so *.coffee.erb would be preprocessed first by ERB and then by the coffeescript compiler. Our goal was to emulate this behavior in SquishIt, and without matching preprocessors to extensions rather than filenames we wouldn't have been able to.

Enabling this behavior is mostly a matter of finding preprocessors correctly. We find them like so:

It's important to note here that "FindPreprocessor" uses the firstpreprocessor it finds for a given extension - so we need to take care if implementing preprocessors for common file extensions like ".js". We can then use the preprocessors in the default order to process our content:

Despite the fact that we have totally broken everything users have come to depend on, we really do want to make the transition easier for people who were using .less or coffeescript with SquishIt. This is where the tremendous WebActivator library comes in. By including this library in our project, it allows us to define bits of code to run when the application starts up, like so:

Thanks to this snippet, you don't actually need to do anything to hook up global preprocessing - just reference the dll containing your preprocessor and WebActivator. This example is from the Hogan preprocessor, submitted by Abdrashitov Vadim. This pull request made me smile more than any I've seen in recent memory - a big part of the reason we moved to this model was to make it easier for people to define their own preprocessors and share them with the community. To have one submitted by a user before we even had a production-ready release was just so cool.

I think this covers most of the changes, at least at a cursory level. I hope to find the time to put together a bit of proper documentation in the next few months, but hopefully this will help in the meantime. I'd like to extend a huge thanks to everyone who reported bugs in our pre-release versions, and to Rodrigo Dumont who provided the spark to get started on this stuff late last year.

SquishIt CDN Support in Previous Versions

I suppose it makes sense to start with what we already had in place. CDN support in SquishIt has been slowly progressing, largely thanks to community contributions. As of version 0.8.6 we did have support for injecting a base URL into asset paths, but this required you to know the generated file name in advance and upload it to your CDN through other means. While this worked, and could be easily automated in your build process, it wasn't exactly convenient. The pull requests we've gotten have done a fairly good job showing us what the community wants in terms of CDN support, so it feels like it is time to start trying to treat it as a first class citizen. The first thing I would like is a way to render the combined file directly to my CDN if it doesn't already exist, and maybe a way to force overwriting the file if need be.

Adding Support for Custom Renderers

For a while now, SquishIt has had an IRenderer interface. It has been there, but it has only been used internally to support rendering to the file system or to an in-memory cache. To get started, we needed to expose this interface publicly so that other assemblies could provide implementations. Once exposed, we need to enable consumers to supply their custom renderers to the SquishIt core somehow.

SquishIt uses a fluent configuration syntax for setting up individual bundles, and that seemed as good a place to start as any. Typical usage looks something like this:

So the first thing that came to mind was to add something like a "WithFileRenderer" method. This would give us a way to inject a renderer into a bundle and have it used to render the combined files. However, we probably don't want to render to the CDN while debugging, so "WithReleaseFileRenderer" might be more appropriate. Setting up the method went something like this:

We also want a way to configure this globally, to do that we needed to add a bit to our configuration class. This was basically the same thing:

Finally, we need to change the way the file renderer is obtained when we go to render the combined assets. Previously we were instantiating a new FileRenderer or CacheRenderer depending on circumstance, and passing that renderer into the main rendering method. This won't cut it anymore, as our needs have gotten significantly more complex. The constraints we have to deal with are as follows:

• When debugging we should use a normal file renderer
• We should favor a renderer configured at the instance level over one configured statically
• If no instance or static renderer is configured we should use the old default behavior

So the constructor calls for a new FileRenderer are replaced with calls to this method:

This is basically all we needed to do to enable us to plug in a custom renderer to use in release mode. Now we can look at how we can make the CDN integration happen.

Building the S3 Keys

The only really tricky thing about building the renderer is that it takes a string representing the disk location to render to. Changing what the renderer takes as a parameter would involve a more significant change to the core behavior than I'm comfortable making right now, so the first thing we need is a way to turn these disk locations into keys that S3 can use. The key we create needs to match the relative path to that of the locally-rendered asset so that injecting the base url will yield the absolute path that we need.

None of this is terribly difficult - the main edge cases we need to cover are

• Root appearing twice in the file path (because of Windows' drive lettering this is mostly an issue running on unix-based systems)
• Virtual directories

To meet these requirements the two pieces of information that we need inside the key builder are the physical application path and virtual directory. Here are some tests:

And the implementation for the KeyBuilder:

Now that we have a means to build keys we can look at implementing the S3 Renderer.

S3 Renderer Implementation

The interface for renderers is very simple.

The only things we'll need to implement this method are an initialized S3 client, a bucket and the key builder we implemented in the last section. By default, we won't want to upload our content if it already exists on the CDN, so we will need to check for existence before uploading the content. This can be done by querying for object metadata using the desired key - if the file doesn't exist we will get a "not found" status on the exception thrown by the s3 client. So the most important test will look like this:

Note that it is checking the PutObjectRequest to ensure that the ACL used is "NoACL". This is probably not an optimal default (most people will want the "PublicRead" ACL I imagine) but I decided to err on the side of caution and force people to opt-in to making their content publicly visible. The implementation for the render method looks something like this:

It has gotten slightly more complex since then (I've added configurable headers and an option for forcing overwrite of the existing file) but the core logic remains the same. It's a fairly naive implementation but my experience with the Amazon services has been good enough so far that I haven't encountered a lot of the exceptions that I hope to add handling for in the future.

Adding Invalidation

At this point we should be able to render our content directly to S3, but this doesn't get us all the way to where we need to be. While hosting static content in S3 offers some advantages over hosting it locally and it can work as a CDN, using CloudFront to deliver your S3 content makes more sense if you really want to minimize latency. To make this work we'll just need to add an invaliator to the mix. A test for the core usage looks like this:

The implementation is pretty straightforward, and will look very familiar to anyone who read my post regarding copying buckets with the S3 API. There are only two changes, first that we only need to invalidate one object at a time, and second that we only want to query for the list of CloudFront distributions once. Code for the CloudFront invalidator looks like this:

As an interesting aside, while I was working on this Amazon released support for querystring invalidation/versioning, which is SquishIt's default behavior. I had planned to add a release note telling people that they would need to use squishit's "hash in filename" option, but it seems like now there won't be any need

Neat, But How Do I Use This?

It's nice that this all works on paper (and in unit tests) but how do we actually tie everything together? One of the key design decisions was that the renderer is instantiated with pre-initialized CloudFront and S3 clients. This way users aren't locked into a certain method of getting credentials or anything like that. To use the custom renderer for only a particular bundle usage would be something like this:

This is nice, but I think the global configuration is probably what people will be using more often. As is common in ASP.net apps a lot of the setup magic for this happens in the app initialization. So you'd add something like this to your Application_Start method (in Global.asax.cs):

I tried to make this something that could be run via WebActivator, but had trouble finding a method to use that would have access to the HttpContext (needed to resolve application path and virtual directory) so for now it needs to be set up manually. This may be for the best though, as it doesn't force any particular convention for access key / secret key retrieval. It doesn't feel like a ton of setup code to me, hopefully others will agree.

What's Next

Now that SquishIt 0.8.7 has been released I can finally start planning to make this available on NuGet as a standard package (currently in beta until I get a little more testing). It can be installed like any other, but will require updating SquishIt if you're using a pre-0.8.7 version. If you need to report any issues encountered while using the library, or feel like contributing some code, please do so on github. Oh, and if you just want to kick the tires on SquishIt without all this other nonsense, or try making it work with another CDN you can find the core library on NuGet as well.

Allowing our content management system to save image changes to Amazon and render their locations in our app was trivial, but we found the push mechanism for moving changes into the live environment a bit challenging. The work for moving database changes was already done when I started on the project, so most of the challenges I saw were in relation to copying the images. What we really wanted was a true bucket copy (emptying the destination bucket altogether and replacing its content with that of the source bucket) - but the REST API for S3 does not support copy at the bucket level currently.

When designing our solution we needed to optimize not only on performance and maintainability, but on cost. The pricing model for S3 has charges associated with most request types so it's not efficient to simply copy all the items in the source bucket to the destination. In addition, this wouldn't handle deleting objects that have been removed in the source bucket. So the naive solution becomes a two step process of deleting all of a bucket's content, then copying over all the content from the other bucket. In a scenario where the actual degree of change is likely to be minimal incurring this kind of cost is not a great option (and it's likely to perform poorly as well). When you add the challenge of CDN cache invalidation and pricing for CloudFront to the equation this looks even less attractive.

This post will go over the implementation we came up with for bucket copying. Code is written in C# using the AWS SDK for .net, but it is all possible using the REST API directly. I will add that the AWS SDK is a very nice tool - typically I would choose to use RestSharp to go directly at the REST API, but Amazon has taken a lot of time to build a nice fluent syntax for building requests and some helper functions that make life easy enough to make it worth a look - it is far nicer than some of the other client libraries out there, in large part because it doesn't try to hide the fact that you're working with a set of webservices. But I digress. The process for copying a bucket is pretty straightforward:

1. Check for destination bucket existence, create if needed
2. List Objects in Both Buckets
3. Identify keys for Insert, Update and Deletion (COPYs and DELETEs)
4. Perform COPY / DELETE
5. Invalidations (Updates only)

So here we go.

Check for Bucket Existence

Checking for bucket existence is a piece of cake, thanks to a static helper function in the .net SDK that takes a bucket name and an s3 client. I chose to hide this call behind an instance method so that I could mock it during unit tests, but this is not strictly necessary. I think that behind the scenes this method simply issues a HEAD request on a bucket and returns false if a 404 is encountered. As you'd expect creating the bucket is done via a PUT request on the bucket resource. Code is as follows:

List Objects in a Bucket

Listing objects in an S3 bucket is very easy. You just need to issue a signed GET request to myBucket.s3.amazonaws.com. The only gotcha is it only returns up to 1000 objects in a single response, so getting a complete list can take multiple requests. It helps to know a few things when putting this together - first that objects are listed in alphabetical order, second that we can include a "marker" parameter in our request telling AWS what key to start with, and third that the response from this method includes an "IsTruncated" flag. The C# code to list objects looks like this:

Identify Inserts, Updates and Deletes

Once we have the contents of both buckets, we need to determine which objects need to be inserted to, updated in, and deleted from the destination bucket. For deleted objects we will be issuing DELETE requests, and for Inserts and Updates we will be copying objects across using a special PUT request. The DELETE requests can be batched, supporting up to 1000 deletions in a single request, while the PUT requests need to be issued on an object by object basis.

These subsets of can be identified by comparing the objects in source and destination bucket. Deletes will include all objects in the destination that aren't in the source. Updates will include all objects present in both buckets that have changed (this can be determined by comparing the ETags on the objects). Inserts will of course contain all objects that exist in the source but not the destination.

C# helps us out a bit here, as LINQ makes it easy to do these comparisons without having to do any nasty looping. For the inserts and deletes we need to spoof an outer join which LINQ doesn't really have a great API for, but I still find it helpful to be able to think about these operations in set-based terms instead of in terms of the tedious iterative comparison that actually gets done behind all the LINQ magic.

Code to identify these sets of objects can be found here:

Perform Insert/Delete

Inserts and deletes are the easy part. We just need to process the list of objects and issue the appropriate requests. There are two important optimizations here - we can batch deletes, and we can parallelize copies. Batching deletes will help to minimize network chatter, and parallelizing copies will help to force as much network chatter as possible into a shorter amount of time I was torn on whether or not to paralellize the copies, but decided that in essence we are performing a ton of blocking I/O requests with another computer doing all the work. If you have real concerns about flooding your network connection you may not want to make this optimization, or do it in a way that allows you to dial down the amount of concurrency but after testing with the calls made in parallel I found a copy of a bucket with ~500 objects finished in about 25% of the time on my dual core laptop, and I was sold.

The inserts are the easiest part:

Deletes were pretty simple as well, only difference being the batching of requests:

Perform Updates

This step is not really anything special but it is different enough for me to exclude it from it's counterparts in step 3. We are basically doing the same copy operation for each object that we did for the inserts, but we also need to worry about cache invalidation on the CloudFront CDN. The invalidation can be batched, so it makes sense to build the list of keys updated while we do the copy, then send a single invalidation request.

So we can change the code for copy to something like this, taking an optional parameter containing a function to add the object's key to a list of keys to be invalidated:

I'll concede that this is not the simplest possible thing - it would probably be easier to call the old copy code and then pass the keys from the updated objects collection, but I do like that it captures the keys of the objects that are actually copied. If we changed the approach to do something like what is happening with the delete operation that trims the collection while processing, the keys collection we pass for invalidation would end up empty. I could also just have too much functional programming on the brain I guess

Once we have the list of keys, performing the actual invalidation is relatively simple. We do need to generate a unique "caller reference" that amazon uses to ensure that duplicate requests aren't processed (remember, each object invalidated triggers some kind of action on potentially hundreds of servers, so this is not a cheap operation for you OR for Amazon). The hardest part is probably identifying whether there is a CloudFront distribution to worry about in the first place. The key to finding whether there is a distribution attached to a bucket or not relies on the knowledge that for an s3 origin, the DNSName property will be "bucketname.s3.amazonaws.com" - so by stripping out ".s3.amazonaws.com" from our available distributions' DNS names we can find if one matches our bucket.

The code for invalidation looks like this:

Tying it All Together

OK so we have all these methods to facilitate copying buckets but how do we actually do it? I'm glad you asked.

Note that the delete happens inline instead of in a separate method as with the copies. This is because it wasn't reusable, and because the act of deleting the items changes the collection. As a result it seemed cleaner to just do it inline.

This is really all there is to it. Hopefully copying buckets in this manner is something that finds its way into the REST API for S3 at some point, but in the meantime this process seems to be working pretty well. It is not the prettiest code, but it runs reasonably fast for our smallish buckets, and I think it is doing a good job minimizing what our customer has to pay for the service each month. It was interesting working on this problem, because it forced thinking about the problem in terms of Amazon's pricing structure (though because Amazon doesn't charge for data transfer within s3 regions it really becomes the same as thinking in terms of minimizing http requests). This kind of thing isn't always a driver of implementation so it was a nice mental exercise. Now we just have to hope they never change their pricing structure

In this case, when you sign up for a task it is supposed to return the updated task, and use this task to replace the notecard into the DOM on the right hand side. It can actually get uglier, as we support signing up for multiple tasks at a time. However, if the session expires we get a big, ugly login page displayed in the midst of all our pretty notecards. What I'd like to find is a way to retain the convenience of using forms authentication, but handle scenarios like this more gracefully.

Adding a piece of metadata to the login page seemed like a good way to get this done without making things any harder on the user. I initially wanted to get the login page classified as an error, so that redirection could be accomplished on the client side using the error callback available when using jQuery for AJAX requests. This would be nice, but in jQuery 1.5 and above a "statusCode" callback has been added that is even nicer. You can use the callback like this:

The ease with which this allows you to define behavior for different status codes is fantastic. As I set off down this path, the most obvious choice seemed to be adding a 401 (unauthorized) status code to the login page, but this got us into a weird redirect loop because forms authentication redirects all 401's to the login page - causing you lose the return URL, and redirect users back to the login page once they are authenticated. Not exactly a paragon of usability.

Having found this out the hard way, I decided a custom status code might be better. It's easy enough to add the custom status code to the login page with a single line of C#:

We can then make our requests using something along these lines:

This works well enough, at least from cassini. When deployed to an IIS server however, we noticed that the 999 status code was getting picked up by the error handling modules, and of course we did not have an error page set up for that code. To get around that we had to add the following to the code to display our login view:

That's kind of nasty, but it seems to allow us to accomplish our goal. I think I can stomach it on this one page in the name of improving the user's experience on the site.

There's one more thing we can do to make our lives easier. There is no special behavior in our statusCode handler, so it would be nice define it only once. Luckily, the folks at jQuery are a step ahead of us. We can define our statusCode handler using the ajaxSetup method in our master page:

Now that everything is set up, we are properly redirected to the login page:

I'm not sure this is the best solution to our problem, but it is certainly a solution. It allows us to keep leveraging ASP.net's built in error handling and authentication (I know they aren't perfect, but they are good enough for us in this scenario) while making the user's life a bit easier in the event something goes wrong. In this case, my team is the primary user of the application so it makes our lives easier

Complete source code for the application in question is available on github.

This can make things a little weird - the primary difference is that both sides of the relationship now need to be aware that they are participants. Say you have the following two classes, and the corresponding mappings (sorry, I used Fluent NHibernate):

This is pretty straightforward, but it does do a little bit of magic behind the scenes. For example, even though the IngredientUse entity is not referencing the Recipe, NHibernate will expect a column called "Recipe_id" on the IngredientUse table in the database that it can use to maintain the relationship between the two entities.

When using an inverse relationship, a few changes are needed. First, you map the collection (from the Recipe's perspective) using the inverse attribute. Also, you need to reference the Recipe from the Ingredient (and the associated mapping). So the inverse mappings look like this:

It's important to note that the updated mapping expects the exact same underlying DB structure. So the model is starting to look a bit more like the database. What this gets you is the ability to save an IngredientUse without first needing to retrieve the recipe you want to add it to. So instead of saving it like this:

You now save it like this:

The difference between Load and Get in this case is worth noting. Load will NEVER return null, it will get your entity or throw an exception. Get on the other hand can return null. So when you use Load, you are essentially telling NHibernate "this entity IS in the database, trust me". That enables NHibernate to use a proxy instead of going out to make sure your entity actually exists. And since we only need the Id, that proxy will never need to go out and load any of the actual object data. I found this especially useful when saving an IngredientUse at the end of an HTTP request.

A perfectly logical side effect (that I didn't consider) to this change is the presence of stale results in NHibernate's second level cache. Because the Recipe's associated collections are cached in relation to the Recipe, and the Recipe is never saved, the collection does not get updated in the cache. I thought I was stuck for a bit, until I found the Session Factory's "EvictCollection" method. This is one of those "use at your own risk" methods, so consider yourself warned. If abused, this could get pretty ugly (leading to a situation where you'd be better off not caching your collections at all). However, I've got an app where I expect far more reads than writes, and I don't think I'll be using it all over the place, so I think this method can be leveraged to solve my problem.

The EvictCollection method's overload that we are interested in takes a string representing the fully qualified collection name, and an object representing the Id of the parent object (in this case the Recipe). So the call we need to make looks something like this:

Easy enough, but the approach leaves a bit to be desired. Because of the magical string, this approach will not be refactoring-friendly, and prone to runtime errors. By using a few LINQ expressions we can do a bit better though. We'll create a class called CollectionEvictor to take care of this stuff for us. But first we'll write a test.

And the class is pretty straight forward as well:

And now we've got something that's a bit awkward, but at least checked at compile time. It seems strange that we need to go through the IngredientUse's link back to the recipe to specify the collection, but that is one of the things that allows us to do it in a generic fashion. The key to making this happen is the LINQ expression type, that allows us to store the lambda expression as data instead of as executable code, allowing us to get much more information about it's signature. By taking its body and casting it to a MemberExpression (thanks Matt!) it becomes easy to get the full name of the Recipe type, and the name of the property referenced in the function. We can then put these together and get our magical string. Because we don't need to execute anything but the call to get the attached Recipe's Id, we don't need to load anything from the database and can use the information our proxy already has.

Assuming there's already a base repository defined, it can be extended like this:

As you can see, this calls the standard Save/Delete behavior, then evicts any collections that have been invalidated as a result of the operation. Implementations can then look like this:

All told this is a pretty naive implementation (You'll need to check for null after casting to MemberExpression, etc...) but I think it shows the idea pretty well. You may not ever need to use an Inverse relationship, but if you do, and need to pair it with a second level cache, something like this might come in handy.

We first tried updating our references to use the 2008 version, and this seemed to work fine. Until people tried to install the most recent builds on XP and 2003 servers the next day. Needless to say, we wanted to avoid building different installers for different operating systems. The application had been running fine simply using the AzMan version found in the server's GAC previously, so we decided to try and find a way to make it work that way.

Eventually we came across the idea of a Binding Redirect and thought this might be helpful. It seems like the redirect only works when pointing to a newer version of a referenced DLL, so we first changed our references to use the 1.0 version of AzMan (from windows 2000) and kicked of a fresh build of the installer. We set up our redirects like so:

At first it didn't work, but looking at the error we noticed that the app was looking for the 2.0 version of AzMan (on a 2003 box where we were expecting 1.2). Wondering if the ordering of the redirects matters, we switched the two redirect lines and restarted IIS. Lucky for us, it worked (on Windows 2008 R2, 2008 and 2003 sp2 boxes).

This isn't something I've had to do a lot, and I'm not sure it's something I'd like to do too often (I may be overly obsessive about local references for a few reasons). But for cases like this where you're working with a legacy component that is tightly bound to the OS AND maintains a pretty consistent interface across versions, it can certainly come in handy.

What is the Session?

This is probably the best place to start. If you're used to working with ADO.net, jdbc, or something similar, it's easy to think of the session as nothing more than a window into your database that allows you to execute queries, like an IDbConnection, but it does a lot more for you if you let it. NHibernate sessions provide a great Unit of Work container, allowing you a great deal of control over how things get written to your database. Unless you are using a stateless session (a session configured not to hold anything in memory) the session will also use NHibernate's first level cache to store objects that are in use, helping you to avoid excessive trips to the database.

What is your Unit of Work?

This is the $64,000 question. Once you know what your unit of work is, session management will more or less solve itself. As you can imagine, this is highly dependent on the nature of the application you're working on. In most cases the unit of work is synonymous with a business transaction. It represents the minimum amount of work that you want to commit to your underlying storage mechanism. This is an all or nothing proposition - if your unit of work requires you to write four objects to a data store, and only three succeed, then the three that succeeded will be cancelled, or rolled back.

Keeping this in mind, a desktop application using an embedded database for persistence may be able to get by with a single session for the life of the application, as long as transactions are properly committed and the session is flushed when the app shuts down. This gives you the benefit of storing a LOT of data in the first level cache, which can be very beneficial when you're positive no one else will be modifying it (though, with an in memory database you may not even need the first level cache ).

At the other end of the spectrum you could find SOA type applications where the unit of work is performed across several round trips between client and server. Using this strategy, subsequent requests to the server need to be able to find their way back to the same session that their work was started with, otherwise they won't have the data they need. In most cases I'd imagine this requires a more complete unit of work implementation that can be persisted across requests and use the NHibernate session under the hood.

What about Me?

Like most people, I find myself somewhere in the middle of this spectrum. My application is web-based, and the primary unit of work can be completed in a single request, so I ended up using a session per request strategy. I found that StructureMap makes managing this a lot easier. I need to first register a Session Factory (as a singleton) with StructureMap. I then tell StructureMap how to retrieve an ISession from this factory (using the ConstructedBy method), and also ensure that it caches sessions per HTTP context. This is all registered from the application layer, but consumed farther down in the persistence layer. Finally, in Application_EndRequest I call a function to clean up anything that StructureMap has cached by HTTP context.

I mentioned that this was the "primary" unit of work, there is one area that this does not cover, and that is authentication. For a while I used built in providers (for SQL Server, then the MySQL provider in MySQL.Data), but when I moved databases again (to postgres) I decided it was time to make a change. Now I'm using a MembershipProvider based on NHibernate, to ensure that it is as easy to move my authentication mechanism across database platforms as it is to move the domain logic. To me, using the session per request strategy didn't really make a lot of sense here because the provider isn't really tied to the HTTP context, but to the application itself. In addition, all data used by the authentication process can ONLY be changed through the membership provider. So, for authentication I keep a single session open for the entire life of the application. This would present some interesting challenges if I were to need to scale across multiple servers, but the code changes to the provider will not be too difficult. In the meantime, I see some pretty good performance benefits from using the single session, as the provider rarely needs to hit the database, or even the second level cache (memcached).

In summary, I find it difficult to offer advice about session management without knowing more about the application. Others have already explained the underlying concepts far better than I could ever hope to, so in a way writing this post feels like a complete waste. But I like writing about my thought process when it comes to matters like these, so I did enjoy writing it. And I think there is some value in sharing this thought process with others, so hopefully at least a few people get something out of reading it. Especially Ben, if he's still reading.

Basically there's an input, and a single slider per input. The slider's name is {input name}Slider. I had some trouble reconciling this setup with the way that the example on the jQuery site is laid out:

My problem was, I couldn't find a way to derive the underlying element's id from the "ui" parameter in the callback specified for "slide". The way I ended up handling this was using the jquery's .each function to configure the sliders one by one. Its' not ideal, but its' also not that much more code, and I doubt many pages I'll be working on have so many sliders that it will become an issue.

I'd be very interested in finding a way to avoid the .each, but I couldn't find anything on the interwebs and this seems to be working for now.

edit: I threw together a quick demo per requests in the comments. You can download it here: jQuery UI Multiple Slider Demo. Hope it helps!

A week or two ago, I found what proved to be my compelling reason. It's a method called

And it does just what it says it does. This could really help in one particular situation encountered in my application (using StructureMap for NHibernate session management in a web context). I need to cache the session factory as a singleton, but the sessions themselves should be unique per request. Before coming across this method I was using a filter to clean up sessions at the end of the request:

This was working fine, but I did need to decorate every controller method where I wanted to apply it. In addition to not really being my idea of a good time, this leaves the door open for me to forget to decorate a method somwhere, causing the app to leak sessions all over the place. Also, if I put it someplace it's not needed, a session will be created only to be disposed of!

So today, I finally got around to upgrading. I made the slight improvements to Registry code that were now possible, but I was most excited to get rid of the filter above, and replace it with this method (in Global.asax.cs):

While there was certainly some pain involved in removing the filter I had used previously, this approach will make my life much easier in the long run. I already trust StructureMap to cache these different instances for me correctly, why not trust it to clean up afterwards as well? It's also nice to know that if I end up needing any other objects to be unique per http context, I won't need to write any more code to clean up after myself. This is a great feature added to the library, and I wish I'd read about it sooner!

EDIT: I saw a thread today mentioning another method called

that's been available since StructureMap 2.3.5 that seems to do the exact same thing. So I didn't really need to upgrade after all, but I guess its nice to stay current. I don't want to make excuses for my ignorance, but I've gotta say accessing it through the ObjectFactory makes a bit more sense to me. In a way I'm more impressed that it showed up there, because its' often a harder decision to relocate code when refactoring than to add it in the first place!