Re: DisableCommit vs SetAbort

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.