ObjectContextManager & Parent/Child/GrandChild Error Handling

cberthold posted on Tuesday, August 04, 2009

I'm having an issue coming up with a way to gracefully handle errors using the ObjectContextManager.

Here is the scenario but it doesn't seem to be related directly to the P-C-GC issue:

I have an
ER(Parent)->EBL(Child List)->ER(Child)->EBL(Grand Child List)->ER(Grand Child)

All managed backing fields and all using FieldManager to fire child updates

My updates on the Data Portals fire as such:
DataPortal_Update[Parent] ->
Child_Update [Child]
Child_Update [GrandChild]

in each of those I am using the ObjectContextManager like so:
using(var ctx = ObjectContextManager<EntityContext>.GetManager(connStr)) {
   ... update stuff
}

I make a booboo in my code (forgot an FK or any error for that matter) and the Rebind has a try catch getting the DataPortalException and shows a nice pretty dialog giving the chance to hit save again and hoping to save your work.  My problem is the Dispose is not being called (or if it is it isn't working) for my relations going down the line.  In this case the error is happening in the grandchild and the dispose never works its way back up the line.  I end up with the reference count sitting at 2 and there is no way to get it back to zero. Calling GetManager().Dispose() of course increases the count and then decreases it still netting me out at 2 references.  This also means the whole application is now hosed because of it and the only way to correct the issue is to close the application.  It was my understanding that the "using" keyword is supposed to work like a try - finally block except when it is a StackOverflowException - only in my case the finally never happens.

Any suggestions as to what I may be doing wrong?  And I guess the bigger question is how do I properly cleanup the OCM after an issue like that?

RockfordLhotka replied on Wednesday, August 05, 2009

What you are observing flies in the face of the rules around the 'using' block, so I'm not sure what's going on.

With a using block, as the block exits (for whatever reason) it should call Dispose() on the object. If that's not happening then there's something seriously wrong.

Either the C# compiler is messed up, or the .NET runtime is messed up, or Dispose() is being called and OCM is messed up.

Please put a breakpoint in the OCM Dispose() method and find out if it is being invoked as expected, that will help isolate the nature of the problem.

cberthold replied on Wednesday, August 05, 2009

I've narrowed it down a little bit. It has to do with the transaction. I took off [Transactional(TransactionalTypes.TransactionScope)]

from my DataPortal_Update and that fixed the referencing issue. Here is the funny part of it. Somehow I think the reference count gets a race condition in it. As it gets down to the grandchild and get the error the reference count ends up doubling in some places. It is truely wierd. The reference count ends up being bigger than the number of times it is called. I'm going to comment this code and fix it so I can move on with life and hopefully sometime this week I can check into what else may be going on unless you have some suggestions?

RockfordLhotka replied on Wednesday, August 05, 2009

The only thing I can suggest is to put breakpoints in the addref and
Dispose() methods so you can see how/when the reference count is changed.

-----Original Message-----
From: cberthold [mailto:cslanet@lhotka.net]
Sent: Wednesday, August 05, 2009 9:25 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] ObjectContextManager & Parent/Child/GrandChild
Error Handling

I've narrowed it down a little bit. It has to do with the transaction. I
took off [Transactional(TransactionalTypes.TransactionScope)]

from my DataPortal_Update and that fixed the referencing issue. Here is the
funny part of it. Somehow I think the reference count gets a race condition
in it. As it gets down to the grandchild and get the error the reference
count ends up doubling in some places. It is truely wierd. The reference
count ends up being bigger than the number of times it is called. I'm going
to comment this code and fix it so I can move on with life and hopefully
sometime this week I can check into what else may be going on unless you
have some suggestions?