I ran into a nasty performance problem recently.  It involved some AJAXy type dynamic requests.  The problem was that two requests always seemed to be occuring serially rather than taking advantage of the wonders of a multithreaded server and running in parallel.  After much spelunking and debugging, it suddenly occurred to me that the handlers were marked with IRequiresSessionsState to pull a trivial piece of information out of the session.

You may not be aware, but accessing the session usually results in an exclusive lock.  Normally, this isn't a problem since users very seldomly open multiple windows or send simulataneous requests, and sessions usually represent unique users.  But fire off two simultaneous requests, and they will be processed serially.

But, if you mark your page as being "ReadOnly" (or disabled) via the EnableSessionState attribute of the @Page directive (or IReadOnlySessionState for IHttpHandlers), you'll help yourself out.  ReadOnly will get a reader lock on the state, allowing multiple readers access, while disabled (via "false") will not lock at all.  In addition, if you're running your session state out-of-process, disabled will keep you from incuring a hit from the db or other store access.

Just an interesting bit of information that thought would be useful.

We had what I deem to be the most beautiful weekend all year.  It was very cool out (70-80 in the afternoon) with a great breeze.  We took the opportunity to air out the house, which was nice because I was back in the bathroom stinking it up...with landscape block adhesive, that is.  I was building the step that surrounds the new tub, which is raised about 8 inches off the floor.  This is primarily to allow for the plumbing retrofitting, but has a nice look to it as well.  It's been a very long project, but is coming to a close finally.  All that's left to do is tile and paint.

For those photo-nazis out there, I have lots of pictures. I just haven't had a chance to get my new photo pipeline up.  I've made some enhancements and I want to make sure they are all working before I throw a few hundred pictures at it from the last several months.

Back on the subject of the beautiful weekend, we had practice for our church's annual juniors vs. seniors football game.  I'm coaching the juniors, so you can bet there will be some crazy plays as I'm not an "American football" person.  Anyway, some of my helpers and I were just providing some generic defense for them and my legs weren't prepared for that kind of sprinting and stopping, and my hamstrings are incredibly sore today.  But it was alot of fun.

My brother, Andrew, and his wife, Sara, have started a blog.  He's piggybacking off of my site for now.  Here's his inaugural post.  Let's hope we hear more from him.

Here's the logic response to Peter's experimenting:

[UPDATE] Since I've gotten some favorable response to this post, both in the comments and in email, I thought I would give some special, behind-the-scenes information

When I saw Peter's pictures, I immediately thought of the series (1,2) of photoshop trickery I did a while back. Look familiar?

Now, if you'll notice, in Peter's original, he is looking straight at the camera.  So, I had to fix the eyes and distort the nose so he's looking over at Jenkies, who is also obviously added to the scene.

After discovering he was in town without warning on Sunday.  I finally hooked up with my friend Jason Jenkins  (whom I affectionately call Jenkies) and some of his friends for dinner.  It worked out perfectly because I ended up leaving work pretty late, so I just met them down on 6th street at Hutz, which is like a 50's diner.  Pretty good stuff.  We got caught up and generally had a good time.  I'm glad that I caught him before he left town tomorrow.

Thanks for letting me crash your dinner plans!

What a geeky post title.  Well, I guess it's a geeky post.

Based on the number of people actually in the bathroom at work when I'm in there, I would think that two people entering/exiting the bathroom at the same time would be a rare event.  Yet, I've come to expect the door to magically open in front of me as my hand nears the handle, or swing violently at my face as I exit.

I always find it amazing the number of things in real life that have dualities in software.  In software, we'd solve the problem of collisions in the doorway by taking a lock on it (although locking on a public object is not always a good idea).  This becomes a problem in the real world because of visibility.  The bathroom door has no window (which is probably good), so you can't see when someone is right on the other side.  You seldom have a collision when the door has a window because you can see who else is going to try to use the door before you can get there.  There are tons of "shared resources" in the world where we've created synchronization mechanisms of various authority.  I think we could learn a thing or two by observing them.

For instance, when roads intersect, we have several different ways of dealing with collisions (we sometimes call them that in the software world as well.):

• Raw intersection - No traffic signs or anything. Typically found on dirt roads where traffic is scarce and the probability of collision is low.
• Yield - One street is a lower priority and "yields" the intersection to the other road.
• Stop signs - you see where I'm going
• Flashing Lights
• Traffic Lights
• Traffic circle - This one always amuses me.  It is actually a very efficient means of managing an intersection IF the drivers are familiar with navigating it.  If they are not, hilarity ensues.
• Overpass

And there are tons of "in-between" flavors.  Hopefully you see what I'm getting at.  The granularity of synchronization in software can be just as complex.  Simple locks, Mutexes, Reader/Writer locks, etc.

Where am I going with this? I don't know.  I just thought it was interesting how many real-world examples of synchronization there are, and how we avoid them in different scenarios, sometimes delegating that responsibility, sometimes taking a more strict position. Prioritizing etc.

That is all.

Yup, it's my Dad's birthday again.  This next year of his life holds alot of excitement for him as he becomes a grandfather.  Happy Birthday Grandpa!

• A generic method with the following characteristics:
  • More than one type parameter.
  • A return type composed of one or more of the method's type parameters other than the first one.

Some C# example signatures (Not useful or practical, just simple examples that show the problem):

static IEnumerable<TValues> FindDictionaryValues<TKey, TValue>(IDictionary<TKey, TValue> dictionary)

static TValue FindAValueInADictionary<TKey, TValue>(IDictionary<TKey, TValue> dictionary)