development

ADO.Net SqlTransactions vs Transactions in SQL

urig — Wed, 20 Dec 2006 23:44:00 GMT

This is a rewrite of a post to microsoft.public.dotnet.framework.adonet.

I'm having a discussion with my team leader concerning the use of
SqlTransactions.

We work on an ASP.Net 1.1 website. Up until now we've been using
ADO.Net SqlTransactions in our business logic layer to combine several data access layer method calls into one coherent, atomic action.

I am in favor of this approach as it supports isolating the business logic from the database and provides for greater code readability.

My team leader diagrees - he thinks that we need to get rid of all ADO.Net SqlTransactions and instead guarantee atomicity by combining data operations inside stored procedures with transactions.

The reasons why he says SqlTransactions are bad are:

1. If one of the running threads in the IIS just dies all of a sudden, it would leave a transaction open and stuck, putting strain on the DB and risking deadlocks.

2. The DBA won't be able to properly debug the SQL Server whenever deadlocks and critical loads are encountered. Because transactions are opened from a place outside of the DBA's scope he will have no way of
knowing how or why certain statements and stored procedures might be executing together or locking each other.

Would you agree with my team lead? Do reason 1 and/or reason 2 justify moving some of our business logic into our DB? If not, does anyone have contradictory examples or links?

I'm calling on whoever is reading this to share their knowledge as I find that I do not know ADO.Net SqlTransaction well enough at this time.

IIS 7.0 is here. Isn't it?

urig — Tue, 19 Dec 2006 21:15:00 GMT

I'm not 100% sure but it seems Microsoft has silently (?) launched IIS version 7.0. This is said to be a part of Windows Vista. Oddly enough I've not seen any launch announcement from MS. Maybe I just missed it?

The new version of IIS is said to implement a lesson from the Apache Web Server - modularity. Functionality previously embedded in older version of IIS has been relocated to modules that can optionally be installed alongside a core IIS server. This would allow for better security as administrators can minimize the surface of the server by including only necessary modules.

Another feature worth mentioning is that the metabase (IIS' registry like configuration settings store) has been dropped in favor of an XML based configuration. Compatability with the older IIS6.0 metabase is served by a Metabase Compatibility component that enables old scripts to work against older metabase APIs.

Via alikl's blog

Team Foundation Source Control won’t Get Latest when you Check Out

urig — Thu, 23 Nov 2006 20:54:00 GMT

In a recent post, Leon Langleyben described a Team Foundation Source Control "feature" that is giving users a hard time. The "feature" is that the Check Out command in TFSC no longer performs a Get Latest on the file checked out, as we were accustomed to in VSS.

In the older Visual SourceSafe, when you checked out a file VSS would get the latest version of the file to your local machine and only then open the file for you to work on. This is critical when working in Exclusive Checkout Mode, which is the most popular work mode in VSS. It guarantees that whoever starts working on the file picks up from the point his predecessor finished and not from some undetermined version in the past.

Having removed the implicit Get Latest operation from the Check Out command Microsoft has yet again shot itself in the foot by shooting its users in the stomach. Teams migrating to TFSC from VSS are taken completely by surprise by the fact that when a team member checks a file out he is not guaranteed to work on the latest version.

Most programmers I've talked this over with describe this new "feature" as a bug. It completely breaks their faith in TFSC as a reliable source control system. When basic trust in it is shattered, TFSC has very little chance of being accepted as the better successor of VSS. My team won't even consider the transition in light of the difficulties one of our team leaders experienced with TFSC in a different company.

How could the TFSC development team make such a terrible mistake? - A harsh usability error that impacts drastically on the marketability of their product. I believe that this happened because the TFSC development team was focused on cutting edge source control strategies and neglected to remember that most of their users are still fixated on the traditional Exclusive Check Out strategy.

Leon describes this as "one of VSTS source control features that is hard to explain to clients". This implies clients are thick headed and I don't think this is the case. I think Microsoft broke the client's expectations without proper warning and needs to fix things ASAP.

I am thankful that the TFSC development team has taken measures to remedy the situation in the next version by adding a "Get Latest on Checkout" command to the system.