Ran in to an interesting problem recently in my current project, we are using the
The problem came when one component published an event through some interaction on the site and the other subscribers would act upon this event by making ajax calls to the server to refresh the data and update the individual components.
I noticed the first call was performing as expected but subsequent calls were experiencing 500 ms waiting before the actual work was being performed. Each of these calls when made individually returned in < 10 ms.
Investigating the issue turns out it is a common problem with being caused by Session State Blocking
__Only one request at a time may have Read/Write access to a particular session (as determined by session id cookie) at a time. R/W access is default
__Any additional requests requiring ANY session access will be blocked until the previous R/W request has completed
This blog does a great job of explaining the issue and providing a fix, which was to add the attribute
So I tried this but the issue still persisted, so I broke out Dot Peek and had a look what was going on in the Sitecore dlls when this was happening and found that the Sitecore.Apps.TagInjection.DependencyResolver.TagInjectionControllerFactory was being used during the ajax calls.
This Controller Factory in the GetControllerSessionBehavior method was hard coding the SessionStateBehavior to Default via the SessionStateBehavior enum and ignoring what had been set via the attribute on the controller.
At this point I raised the issue with the awesome guys at Sitecore support and the confirmed this behaviour is in fact a bug in Sitecore 8 Update 3 and have provided a fix via a dll and config file. The bug reference number is 449003 if you are seeing the same problem get in touch with the support team.