We encountered the same random Zombie.  A few months ago, we opened a support incident with Microsoft.  After many (many...many...many...) hours of troubleshooting, researching, escalating, and finger pointing, Microsoft finally conceded that this is a bug with ADO.Net.  In specific, it's a bug with the SqlTransaction object.  It will be fixed in a "future version" of ADO.Net, but a hotfix will not be issued since this is an "obscure scenario with a simple workaround."

I won't bore you with details, just a fix. 

Don't use the SqlTransaction's Connection property.

Check the source code for the ORMapper and you'll find that Internals.Connection.GetTransaction connects to the database, begins a transaction and returns the IDbTransaction.  The calling method (the Transaction constructor) then assigns an internal reference to the IDbTransaction's Connection property.  What we found was that every once in a while, the IDbTransaction's Connection was NULL!!!!  This ended up to be the root of the Zombie issue, which manifested itself later when we called PersistChanges. 

The reason the Connection was NULL is really quite odd.  In ADO.Net 2.0, the SqlTransaction was modified so that it has two references to the SqlConnection used to create it.  The first is the publicly exposed Connection property.  The second in a private connection property.  The private connection has a weak reference to the public connection. 

Since the SqlConnection is created inside Internals.Connection.GetTransaction, it goes out of scope when the IDbTransaction is returned to the Transaction's constructor.  At that point, the Connection is eligible for Garbage Collection.  Every once in a while, the GC collects the Connection object between the point the Transaction is created and the point you PersistChanges. 

We fixed this using the following code:

1)       Modify the constructor of the Transaction class:

            internal Transaction(Context context, IsolationLevel isolationLevel) {
                  this.context = context;                  
                  //in .NET 2.0 is to keep a reference to the outer connection of the transaction
                  //
                  //OLD CODE
                  //this.transaction = this.context.Connection.GetTransaction(isolationLevel);
                  //this.connection = this.transaction.Connection;
                  //
                  //NEW CODE
                  this.connection = this.context.Connection.GetConnection();
                  this.transaction = this.connection.BeginTransaction( isolationLevel );
                  this.context.Connection.InterceptCommand(this.id, null, CommandInfo.BeginTran, null);
         } 

2)       Modify the Internals.Connection class

a.       Remove the GetTransaction( String isolationLevel ) as it will no longer be referenced

b.       Add new method GetConnection() which will return a connection to the database:

Happy Hairpulling,

Rob

I can definitely acknowledge that you and a few others are obviously encountering a very real problem.  I hesitate to call it a bug since I know the previous problem like this that I had fixed was due to a bug in ADO.NET.  But nonetheless it does seem to be a new issue, so it may well be a bug too, and no matter what it should be fixed.  On the other hand, I know that I and many others run quite a few applications that have never ever encountered this issue.  That has certainly contributed to my not forcing myself to have to find the time to look into this, and unfortunately I just am not getting things done that I would like to do, including finishing already started stuff.

At one time I believed that I just needed to change my job situation, as the one that I was at had grown to expect too much of my time.  About the time I changed jobs my wife changed positions and started working a very very early morning shift.  I thought I would adapt but I never did, and she has now found a more normal position.  So now I find that my current job is not expecting too much, and my home life has finally gotten mostly back to normal, but I am so far behind on what I want to do on my own that its gotten depressing.  Meanwhile its been so long since I've had free time that I've been enjoying spending it in other ways, which just adds to my delays.

That's probably not what you were asking for when you asked me to comment, but I hope it does clarify where I am at.  I believe I was always clear from the beginning that my ORMapper was something that I found useful for myself, and that was why and remains why I created it.  Of course instead of sharing my code for free I charged $50, but that was always because I felt it was a significant amount of code, and not because I was trying to become a software vendor.  I think most people have understood this and not expected to much, and to that end I've actually went far beyond that in my upkeep of the ORMapper, even better than some real vendors if I dare so.

Unfortunately that may have created the impression that I was always going to make this my priority, but as much as I sometimes want to, that simply is not and cannot be my reality.  So while I do still hope to make the time to make another official release, including this bug fix, I'm also very happy to see that Rob has apparently fixed it since I haven't found the time.  In the meantime, I hope that you and others continue to find the ORMapper to be useful once you get this bug fix in place, as I know I and many others have.  I do hope to either update it for Linq, or if Linq is good enough then I want to update my Portal to Linq -- whatever I find useful myself again, and hopefully others will agree.

I should stop myself now.  :)

Thanks, Paul Wilson