COM+ Transactions - Time-out

After implementing a transaction for a specific method in our application, we were unexpectedly faced with a Transaction rolled back error. At the beginning, we really had no clue what was the cause of this because the transaction sometimes completed successfully on other computers for the same environment and for the same action we started.

After some research and thinking, we concluded that it had probably something to do with a time-out. The default time-out for a transaction is set to 60 seconds. It must have been that our transaction finished just before those 60 seconds on one computer while it wasn't completed yet on another computer in that timeframe. These kind of errors are often hard to find and reproduce, but luckily it was easy to solve and to avoid our Transaction rolled back error.

Also while debugging in a development environment, a transaction may time-out before it is committed or aborted (due to breakpoints and waiting times). To avoid a time-out, you must use a time-out property on the transaction attribute and choose a time-out (in seconds) according to your specific needs ...

  [Transaction(TransactionOption.Required, Timeout=120)]

You can also set this manually on the component in Component Services (Transactions Tab), but I prefer to set this as a property in code. When your assembly gets registered in COM+, everything is automatically done for you and you (or most of the time some other dude) won't change by any chance the default time-out for all COM+ applications on the server because there's also a global transaction time-out. You don't wish this to happen when there are other components registered in COM+ on that server, especially if you are decreasing the time-out value!



It's also good practice to limit the time a transaction takes in code. I mean that you should start a transaction as late as possible and stop it as soon as possible.

Team Foundation Workgroup Edition (2)

After my first attempt, I decided to reinstall everything with domain user accounts.

All installations (SQL Server 2005, Sharepoint Services, hotfixes, ...) went fine until the installation of Team Foundation server. The health check was still OK (except for the known warning) so I could click the Install button, but the following error popped up after a few moments ...

Error 28925. TFServerStatusValidator: Calling the Team Foundation Server ServerStatus Web service failed. Additional details about the problem can be found in the setup log. Verify your network configuration. For more information on troubleshooting this error, see the Microsoft Help and Support Center.

After I while I figured out that there were definitely some problems connecting to my localhost (IIS) during the setup. The setup of TFS requires some webservices that run on the server and the addresses could not be resolved. Apparently I had still left the configuration script active in the Internet Options (tab Connections - Advanced) of my browser and this script is used to browse the Internet when I'm logged on to my company domain. My localhost could not be contacted through this configuration script.



Turning this off and a restart of the TFS setup fixed this issue. Done!

Downloading ...

My downloads have started (nice speed by the way)!



Microsoft released Windows Vista beta 2, WinFX Runtime Components Beta 2 and Office 2007 Beta 2.

Question : how will I find enough time to install all this (correctly) and work/experiment with it? I'm not even mentioning Visual Studio Team System (see previous post) ...

Team Foundation Workgroup Edition

The installation guide has to be followed step by step if you don't want to run into all kinds of trouble. At the start of the installation, a health check is run to check all prerequisites. Although I'm running a pretty powerful laptop (1.86 GHz - 2 GB of RAM), I was warned that my system did not meet all system requirements for installing Team Foundation Server. System Requirements are 2.2 GHz Pentium IV!

The first thing I did was creating the required TFS accounts (TFSSETUP, TFSSERVICES, TFSREPORTS) on my system. I used local user accounts for running setup and services. I wish I had used domain user accounts. More on this later ...

After that, I installed IIS, SQL Server 2005, Sharepoint Services, some hotfixes and eventually Team Foundation Server. It's handy to know you can install Microsoft SQL Server 2005 from the command line using the provided answer file. This answer file automates setup to install and configure Microsoft SQL Server 2005 for use with Team Foundation Server. It saves you at least some time and clicks in the entire installation procedure.

So far so good. I almost had a working environment ... The only thing I still had to do was to add the appropriate user accounts (maximum 5 for Team Foundation Workgroup Edition) in the Team Foundation Licensed Users group. This is the point I come back to the use of the local user accounts for the installation. I wanted (of course) to add my domain account to this group so I could experiment from that account, but as you may predict : it didn't work ...

Received error :
Team Foundation Server could not resolve the user ... The user or group might be a member of a different domain, or the server might not have access to that domain. Verify the domain membership of the server and any domain trusts.

Apparently, only local user accounts may be added to this group and this is probably the result of the Team Foundation installation with the local user accounts. This is what I found in the installation guide ...

If you install Team Foundation Server using local user accounts for running setup and services, you cannot add domain user accounts to Team Foundation Server and they cannot create projects.

Rob Caron has posted this as following :

If you choose to install Team Foundation Server using workgroup accounts, you are limited to adding workgroup accounts as users when using Team Foundation Server. That is to say, you cannot add domain user accounts to Team Foundation Server that is using workgroup user accounts to run its services. The reason is fundamental; a service that is using a local workgroup user account logon cannot access a domain controller to authenticate a domain user account.

Ok, I can still work under a new local user account, but that was not my initial plan and I will be often forced to switch user accounts ... Damn! Decision time ... reinstall?! So I need those separate domain accounts on my corporate domain?! Could be interesting that other people can also connect to my Team Foundation Server ...

Something else that didn't work was the specification of the logon account for the Team Foundation Build Service during the install of Team Foundation Build. It's not possible to enter a local user account for the Service Account. Only Windows domain user accounts are allowed ...



Not quite finished yet! Any experiences with this?

Interesting links

Some interesting links I've picked up in the blogosphere lately :

• Microsoft Feeds Directory
• TechEd Europe 2006 [Barcelona]
• Hands On Labs for Entlib 2.0
• ASP.NET 2.0 Membership and Roles Tutorial Series
• MSDN Connection Belgium & Luxembourg

Overloaded inboxes

Back at work after my 3-weeks honeymoon I was faced with overloaded inboxes (email at work, email at client, private email). The problem of email overload is taking a toll on our precious time and productivity because most of us lack a cohesive system for processing emails and converting them into appropriate actions.

Attaining ZEB - a nice acronym for an empty inbox (Zero Email Bounce) - is crucial in my effort to gain control over all my messages. I only move (or delete) a message to a dedicated folder when work for that message is done. Work can be a quick reply, a meeting request, a phone-call, a new task in my task-list, ... Having an empty inbox doesn't mean that all tasks are done, but it means that I know at least what my tasks are!

One thing I would like to add next time when I have no access to my account for a longer period, is a more clear flagging system. When I have for example more than 500 messages in my inbox, I want to see immediately which messages could be important and need my attention first. Outlook 2003 introduced colored follow-up flags for users to categorize their emails. Setting different flags when messages arrive can be easily done with the Rules Wizard in Microsoft Outlook 2003. Key is the definition of an important message!

Nowadays we don't have to worry about finding back a particular email because we can rely on software like Windows Desktop Search and Google Desktop Search, but it's certainly a good practice to store/archive your emails in dedicated folders when you move them from your inbox.