Re: 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)" <[email protected]>
To: <[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.
> 

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