Re: DisableCommit vs SetAbort

Hi,

Jesse is right. One of the most important reasons for that kind of error
is that you do not explicitly raise an error in your component. And this
is even the bset thing may happen because your clients may crash without
even letting you know about "method ~ of object ~".

While it may seem pretty basic and you may already know better means of
doing it, I think the best practice is:
1. In every method write a handler which sends error object, name of the
module and name of the routine to a global error handler defined in your
code module.
2. Define a public error enum in one of your classes
3. In global error handler check the err.number and based on that, raise
proper error with your own number defined in enumeration.
4. In your "else" case, raise a non-specific error with its description
being error object description.

This way no error leaves your component without letting its client known
about it. Even when you have 3-4 layers of components, with having a
proper error handing/raising, errors would bubble from the database
layers up to the presentation layer.

Cheers
Ali

-----Original Message-----
From: Jesse Sanders <[email protected]>
To: [email protected]
Date: Mon, 22 Jul 2002 08:23:59 -0600
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.