The Professional Developer Series #1 – Source Control Discipline

I believe that every developer is using some kind of source control software. Be it distributed source control like Git, Mercurial etc. or centralized ones like SVN, TFVC and Perforce. If you are not using source control (why?) or if you don’t know what I am talking about, please read this – Why should I use version control?.

Proper use of source control software is essential to software development and yet few software shops practice it correctly. This is because writing code is seen as the primary task and correctly managing the process of writing code is a secondary concern. This prioritization is correct to some extent and does make business sense. You need to ship on time and ship with new features. There’s no luxury to ask the customer to wait just because you want to sharpen your metaphorical developer axe. Usually, a developer will finish working on a feature, check in all the files that have been changed and then forget about it.

Granted, in most enterprise development environments, where time is limited and developer focus is on feature delivery and bug fixes, you don’t normally have the luxury to worry about readability, loose coupling, maintainability and performance of your code when the business user is breathing down your neck to release the next feature. But let me show you why it is worthwhile to focus on what you check in and how it will save you time in the long run. Continue reading The Professional Developer Series #1 – Source Control Discipline

ASP.NET Request Queuing surprise!

You know the time you use a development platform for years and begin to think that you can finally think of yourself as a veteran in that technology. And then you find a problem that challenges your understanding of the framework and you begin questioning yourself. Well, this is precisely one of those times.

I am a .NET developer working with ASP.NET websites for a few years now. I was adding a new feature to an existing ASP.NET Web Forms application when I encountered this. Since we are in 2017 and full page refreshes are “out of fashion” and everything has to be done with JavaScript and AJAX, I decided to implement the new feature with a little flavor of asynchronous JS call to the back end.

The application had an existing web page that would call another web service which was known to be notoriously slow. Any time you would try to load this page, it would take more than a minute for this page to load.

While working on the new page, I happened to open the slow page in another tab right before I tried to test the new AJAX call. The browser was waiting in another tab on this slow page and I was on the current one waiting for the AJAX call to respond.

What I noticed was that the AJAX call did not respond till the first slow page finished loading in another tab. It would normally take less than a second to respond. However, it finished right after the first request was completed.

This was surprising and it appeared that the AJAX call was queued behind the first slow request. This should logically not happen as we have multiple threads on the server which can service more than one request at a time. This is IIS, a mature web server and it cannot be the case that it can only respond to one request at a time.

After making sure the behavior was repeatable in a test web application, I checked the application pool settings on IIS to make sure all the settings were sane and preferably set to default values.

After some googling around, I came across these articles:

And there it was! ASP.NET locks the session object during the request life cycle. This means that any request from the same user will queue behind a previous request!

This means that as a user, it is of no use to open a another URL in a new tab in the same application while another page is loading. The second request will not begin executing until the first one has finished. The second request will simply wait for the first one to complete before it gets to lock the session variable for itself and continue execution.

Now this seems highly inefficient at first sight. Why would anyone implement a web server in such a manner. But it seems that this is a very old behavior from the early days of ASP.NET when we did not have a web full of client side frameworks and asynchronous requests and the priority for web platform developers was to keep the desktop to web transition simple for existing developers. Microsoft sacrificed performance in favor of the integrity of the session variable. I would agree that for the time, this was the better decision as we developers did not have to worry about race conditions in our code and access the session variable freely in the request pipeline. This essentially makes the session variable thread safe.

However in today’s world, where many of the applications have moved to client side platforms and frameworks like Angular, React etc. Session locking can be a severe limitation to the scalability of the web application if you happen to have some slow pages.

To be fair, if you opt out of session state or reduce the session state to read only mode, you will not face this behavior as it only applies to requests that can write to the session state. However it is a gotcha that needs to be considered when working with ASP.NET.

It’s humbling to know after working all these years as a .NET developer that something so crucial can go unnoticed for so long.

Learning something new every day… 🙂

Oracle ManagedDataAccess the way forward for connecting .NET applications to Oracle databases

If you have spent any amount of time working with Oracle databases as your back end, you know you have dealt with issues related to Oracle client installations. The client comes packaged in a large installer that installs a lot of other stuff along with the required drivers to connect with Oracle databases.

To be fair, the Oracle server component is in fact quite robust and comes with all the bells and whistles required for enterprise grade RDBMS software.

The problem is with the client itself. Should you install 32 bit or 64 bit version if you are on a 64 bit OS? How do I easily deploy to a clean slate machine without the large Oracle client already installed?

The good news is that all those issues are past if you are a .NET developer. You now have a 100% managed code driver in one package! The Oracle ManagedDataAccess library. It is completely native managed code unlike the Oracle DataAccess library which was just a .NET  wrapper to talk to the native binaries of the Oracle client.

What does this mean for the average developer? Well, no more Oracle client installation! No worries about 32 bit or 64 bit installations as it is targeted for AnyCPU. All you have to do is import the library as a nuget package(you are using nuget, arent you?) and you are DONE! You have everything you need in one small focused dll. It is packaged with your application as just another dll in the bin folder.

It was a long road to reach here. The journey was somewhat like below:

  1. ODBC drivers (remember the “good” ol’e days when you had to open Control Panel to set up ODBC connections? anyone? 😉 )
  2. Microsoft OLE DB provider for Oracle(the msdaora.dll one)
  3. Oracle Provider for OLE DB(based on the now legacy ADO technology but was an improvement over the Microsoft drivers)
  4. Oracle Data Access Components (ODAC/ODP.NET, which came initially with only a .NET wrapper to the native Oracle client dll’s)
  5. The ODP.NET from 12c onwards (this release provided the ManagedDataAccess library which is completely self contained and doesn’t require any Oracle client)

There is a small gotcha though, the completely managed drivers don’t support all the functionality of the previous Oracle .NET drivers which were a wrapper on the native Oracle client. But as per my experience, it should suffice for most the .NET developers making CRUD applications for businesses.

You can refer to Oracle Data Provider for .NET Developer’s Guide on the missing features in the managed driver.

If you don’t depend on the unsupported features, the new driver is a big leap ahead. You now have the following advantages:

  • No more installation of a large Oracle client
  • No worries about choosing 32/64 bit architecture
  • Easier deployment as it is completely self contained
  • Cleaner deployment as we don’t pollute the server with unneeded tools and utilities

You need to change your namespaces from Oracle.DataAccess.Client to Oracle.ManagedDataAccess.Client if you are migrating from the previous drivers and most of your code remains the same.

This is what Oracle has said about the new driver (emphasis mine):

ODAC 12c will be out on OTN and you can download that version. That will be our latest and greatest managed ODP.NET version

I believe any application using the old drivers should be migrated whenever possible and any new development should be done only using the latest driver as it is a big leap from the older versions. You cant beat the benefits and compatibility provided by a 100% managed, self contained driver. Moreover it’s less than 10Mb in size!

So go ahead, leave the Oracle client behind and forget the days when you had to decide between 32/64 bit installs 🙂

Hello World!

Welcome to the blog! I am a software developer working on the C# and ASP.Net stack. This is where I will be posting anything and everything about software development, the latest in technology, tutorials, opinions,  and any other thing of interest to fellow developers.

Content coming soon 🙂