Recently our team has been working on porting our existing ASP.NET Intranet application to Smart Client.
All the existing ASP.NET applications use 3-tier architecture, where we have ASP.NET as User Interface, Business Facade and Data Access in C# Components. We decided to replace ASP.NET front end with WinForms and reusing the same set of business facade and Data Access components. To speed up the business validation process we decided to download the business facade along with the UI in the client machine.. The Data Access Layer will remain in the Server and will be Remoted.
In the web version, the business facade will start a Transaction and perform method calls in multiple data access components(by passing IDBTransaction) to perform a logical business operation.
In order to keep this architeture when we move to smart client we decided to remote the IDBTransaction (The remote component will be a Client Activated so every client gets its own Transaction and the state will be maintained across server calls).
Everything was fine till this point.. The problem started when we decided to host the Remote Components using IIS. The Remote Component holding IDBTransaction seemed to be losing the underlying connection occassionally... At first we thought the issue was with configuration or someone doing iisreset on the development servers.. But it started happening again when we moved our code to the QA servers.. So we decided to get down to the details of whats happening behind the scenes. I decided to run SQL Profiler to monitor the events in the Server. There is a windows service running in the web server looking for some data in the database every 5 seconds which was adding too many information in the SQL profiler so I decided to turn off that service... and to my surprise the Remote IDBTransaction started working without any problem .... ooohh !! so we were able to nail down the source of the problem..
Let me explain the sequence of events happening :
1. The Remote Component opens a Connection.
2. The Remote Component opens a Transaction.
3. The Windows Service opens a connection. (At this point the connection created at step 1 is closed and is given to the Windows Service)
4. The Transaction started at Step 2 is Rolled Back since there is no underlying connection.
We thought the problem could be because of the Connection pooling (even though it would be foolish to think how a connection could be pooled across a windows service and Remote Component hosted in IIS).. To prove this point we created two different registry keys for opening the connection from Windows service and the Remote Component (since both the Windows Service and the Remote Component were using the same registry entry for getting the connectionstring..) But this didnt solve the problem .. So we knew the connection pool was the not the problem..
At this point we ran out of answers.. So the last option was to try hosting the Remote Component in a Windows Service rather than IIS... and that solved the issue... We are convinced that there is some underlying issue with maintaining stateful components (especially IDBTransaction) within IIS... I tried googling this topic but couldnt find any info.... I am sure someone will have the same issue as me when they try to host Remote Components within IIS.