Today was a great reminder of a known helpful tip. When you get heavily involved with a project and you have been working on it non-stop for several weeks, it really pays off to set a day that you do not work, think, or even consider the project you had been working on. Why? Because a step back will likely give you a new perspective on the project (Tip #1).
The bridge I had been working on for months, has had three known issues all that were complicated in various ways, or at least that is what my brain told me. For the past few days, I have been working on a different project and thus my mental focus was not even close to this bridge application. Today, I started to work on the remaining issues and things just snapped. I knew exactly where to look to find the communication issues and I knew exactly what was necessary to solve them. I got through one of my biggest issues (which had 5 minor issues attached to it) throughout the morning. Come afternoon, I was working on the second and third problem (of which I had a meeting about with two other developers) and I got really close to solve the second issue, but then my brain was back to playing tricks. It just decided it couldn’t figure out the issue entirely.
That was fine by me. Within the first 30 minutes of our meeting, one of the developers had it solved and I had the code written and proven to work. Another 40 minutes later, the final issue was resolved. This is TIP #2. A look from a second or third developer will eventually leave you with less headaches, as they will see what your brain has decided not to see. It has been proven that your brain can play tricks on you. The code you are seeing with your eyes might not really exist, but your brain knows that is what you were expecting to see, so that is what it presents.
I forget the technical term for this behavior, but you can easily read about it in any psychology book. Most of the examples use patterns, with missing pieces and your brain magically fills in the piece that was missing. Finally, Tip #3, is do not forget Tips #1 and #2! I cannot stress that enough. Without the first two tips, you will eventually break down. As a programmer, cope with asking others to look at your code and determine what is wrong. It does not mean you are a bad programmer.
As a programmer/software developer, there are days that are just mentally exhausting. Today was one of those days for me. I have been working on a bridge to allow two systems to easily communicate with each other for the past month (really, i should say, I have been working on it off and on, you know how priorities go…).
The bridge is fairly straight-forward, if you completely know the products you are bridging together. However, I had to bridge eight different applications with another outside (as in, outside our network) application. Three of the applications I know very well, as I played a significant role in their development. One of them I knew fairly well and could easily figure out as it was written in an old language our company used that mimics JavaScript. Three of them, of which I have had no interaction with were also written in the older language, and so I figured them out, but it took more work than the prior applications. Finally, the last one I have hardly had any interaction with and it is in .NET… yet it is the one that has been giving me troubles for the past week.
.NET is easy and overly complicated at the same time. Poorly designed code can quickly confuse even the best of minds. Then add on code that is written in the application but never physically used, just adds on to the complication and torments the developer trying to learn how this program works. That was today in a nutshell. Code found in one place that looks exactly like what you wanted to see, ends up never being used throughout the rest of the application for unknown reasons and to top it off, when you ask the developers who work in it on a daily basis, they too have no idea why that code exists.
Don’t get me wrong, I am not here to bash the previous developers who wrote this mysterious code, but to give myself a mental note. Remove code that is no longer used from the project as soon as it makes sense to do so. Leaving it behind will only lead to greater complexity and much more confused looks on future developer faces. None of that is necessary and I for one do not want to me the reason for their headaches or confusing moments.
On the plus side of things, I got my issue worked out with the bridge and only have five more pieces to get the communication working smoothly. Plus, after racking my brain for several hours today sorting out the complexities and the confusing code, it is just FANTASTIC to see the part work right before my eyes so I know I figured it out entirely.
Over the past year at work the projects I have been working on use Sessions to carry data from one page to the next. The data primarily stores the location in Persistent Storage where we are keeping the user’s data until they have finished their task. At this moment the problem does not exist but it will be an issue in the upcoming future.
The Issue:
Our problem is that if a user runs one of our web applications in two windows, the data will get mixed between the two sessions as the two windows share the same Session ID, as the Session ID is typically taken care of by the Browser.
In Internet Explorer, if you start two processes by running “iexplore.exe” each process will have a different Session ID, thus the issue does not exist. However, if you open one process and then do a File > New Window, the second Window reuses the first process and thus contains the same Session ID, or if your original window pops up a second window using JavaScript, the new Window will contain the same Session ID.
Likewise, if you have a Web Document shortcut on your desktop or in your Quick Launch bar that links to a particular website, the second, third, etc time you click on that shortcut it will reuse the first process of “iexplore.exe” and thus each subsequent click will use the same Session ID.
Firefox, Opera, etc no matter what steps you take to start them will always use the same Session ID. At least that is what my initial testing showed.
The Solutions:
There are two solutions I will talk about in this posting. The first deals with using a Unique Identifier in the Session Name, and the second deals with using Cookieless Sessions. Personally, I like the latter as it tends to require less coding changes.
Unique Identifier in the Session Name:
The first step would be to establish a unique identifier, most .NET users will understand the word GUID (Globally Unique IDentifier). Your session name would be something like “SessionName-<GUID>” or “SessionName-2345-234-2345-23456″. By doing this you have guaranteed a unique session for each instance of the application. After which you will have to pass the unique identifier to each corresponding page either by QueryString or a Hidden Form Field.
Hence the downside, each page will have to be able to read the value of the Hidden Form Field or QueryString, thus requiring several code changes to your existing applications.
Thus, I rate this change as a “Moderately Intensive” solution, as it will be tedious to change several pages in your existing applications to handle the Unique Identifier approach.
Cookieless Sessions:
Cookieless Sessions are extremely easy to do in .NET and only require a web.config change. Here is how it works.
When the user requests your application using an “absolute url”, a Unique Session ID is automatically generated for you and is placed in the URL of the browser like so “/applicationsFolder/(unique session id)/pagename”.
The problem is, once your application is started you will need to use relative urls to go to the next page, previous page, etc. Otherwise your application will generate a new Session ID and you will lose all data you have kept track of for the current user.
This includes pop-up windows that need to access the session data along with form action urls.
Along with the guarantee of a Unique Session ID, Cookieless Sessions are faster than Cookie Sessions (sessions handled by the browser). The main reason, is the browser no longer handles the Session Information to send it to your application. In short this means, the browser no longer has to read the session off your hard drive, setup the header information, and then send it to you on the Request for your application’s page, all because it is now embedded in the URL.
For these reasons, this is why Cookieless Sessions has my choice for best use when your application needs to be able to run multiple sessions for a single user.
In Summary:
Cookieless Sessions and using a Unique Identifier in the Session Name, can both solve the issue of running your application on two different sessions thus preventing data collision or data mix-match, however, they both share the same problem when it comes to bookmarking or copying and pasting a URL to someone else for help. Bookmarking and copying the URL will contains the Unique ID or the Session ID, thus the one major downside. However, if your application does not need to handle bookmarking or the copying and pasting of URLs, these solutions will be of great benefit.
Cookieless Sessions differ from regular sessions that are handled by the browser to send your application the Session ID in that the browser does not handle that aspect anymore, instead IIS with the help of .NET creates the Session ID in the URL and takes care of reading that ID for your application to use.
I hope this information finds itself useful to many others as I know it was well worth discovering for me.