Re: DisableCommit vs SetAbort

Many thanks, Jesse - this is what we have gone for.

-----Original Message-----
From: Jesse Sanders [mailto:[email protected]]
Sent: 22 07 2002 15:24
To: [email protected]
Subject: Re: [VBCOM] DisableCommit vs SetAbort


James,

I have done exactly what you are talking about and it works fine for me.
The main reason I have seen the method ~ of object ~ error is usually due to
not raising errors out of COM+/MTS objects explicity.  Do not allow errors
to raise out automatically.  Trap all errors and then call Err.Raise.  This
should solve your problem.

HTH,

Jesse



>From: "James Brophy (CharcolOnline)" <[email protected]>
>Reply-To: Technical discussion of VBCOM <[email protected]>
>To: [email protected]
>Subject: Re: [VBCOM] DisableCommit vs SetAbort
>Date: Thu, 18 Jul 2002 13:25:32 +0100
>
>Many thanks for the replies.
>
>I think the problem I was ultimately getting at was this:
>
>We use the Event Log to report Errors. Calling SetAbort in a Secondary
>object then raising an error to the Root means our error messages get wiped
>- becoming "method ~ of object ~ failed".
>
>To get around this we propose to use DisableCommit in our Secondary objects
>(and Set Abort in the Root).
>
>I wanted to check that we were on the right track.
>
>This bug (not in MTS) but in COM+ was supposed to have been fixed in Win
>2000 SP 1 (though we still get it). Can anyone add to this last point? Has
>it been addressed in SP 2?
>
>Once more, thanks for your help.
>
>James
>
>-----Original Message-----
>From: Alireza Kheyrollahi [mailto:[email protected]]
>Sent: 17 07 2002 23:28
>To: [email protected]
>Subject: Re: [VBCOM] DisableCommit vs SetAbort
>
>
>Hi,
>
>I believe this topic can be very confusing and somehow controversial
>regarding the best practices.
>
>But generally, disableCommit is used whenever you would like to tell the
>root object that the job has not been done and root object can decide to
>e.g. call another method of the that secondary object to make it happy. It
>means that the error is potentially non-fatal.
>
>Suppose a root object asks a secondary object to get fresh data from
>database but that object just informs root object that connection is closed
>and fresh data is not available. So now root object can decide to call e.g.
>getCachedData method of that secondary object (which in this case secondary
>object would call setComplete) or to just finish he job by raising an error
>in case it needed fresh data.
>
>But if the task is important in a way that there is no way for the root
>object to make the secondary object change its mind, I think there is no
>point in just calling disableCommit because you are keeping your secondary
>object in memory without needing so.
>
>From Ted Pattison's first edition book:
>
>
>As you might imagine, using DisableCommit requires you to design a more
>elaborate communication protocol among the objects inside a transaction.
>When a secondary object calls DisableCommit, the root object can try to
>persuade the object to change its mind by executing additional methods.
>However, the root object must ultimately call SetComplete or SetAbort.
>Therefore, the root object must find a way to make the secondary object
>happy or determine that the transaction can't be saved.
>
>
>Cheers
>Ali
>
>
>
>
>
>----- Original Message -----
>From: "James Brophy (CharcolOnline)" <  <mailto:[email protected]>
>[email protected]>
>To: <  <mailto:[email protected]> [email protected]>
>Sent: Wednesday, July 17, 2002 2:07 PM
>Subject: [VBCOM] DisableCommit vs SetAbort
>
>
> > Can anyone tell me what the practical difference between the Root object
>in
> > a transaction calling DisableCommit and SetAbort on failure / an error
> > raised by one or more Secondary objects?
> >
> > Basically, design-wise, I would like to have all Secondary objects call
> > DisableCommit on failure / error; and all Root objects call SetAbort on
> > handling such a failure / error. Can anyone supply a reason not to?
> >
> >
> > Many thanks,
> >
> > James Brophy
> >
> > You can read messages from the VBCOM archive, unsubscribe from VBCOM, or
> > subscribe to other DevelopMentor lists at  <http://discuss.develop.com>
>http://discuss.develop.com.
> > You can read messages from the VBCOM archive, unsubscribe from VBCOM, or
>subscribe to other DevelopMentor lists at http://discuss.develop.com.
>
>
>You can read messages from the VBCOM archive, unsubscribe from VBCOM, or
>subscribe to other DevelopMentor lists at http://discuss.develop.com.


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

You can read messages from the VBCOM archive, unsubscribe from VBCOM, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.

You can read messages from the VBCOM archive, unsubscribe from VBCOM, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.