--- Ron Jacobs <[EMAIL PROTECTED]> wrote: > [Ron Jacobs] You could simplify your design by passing x,y,z to the > TransactionalMethod every time, or you can call DisableCommit which will > cause your object to not deactivate. Then you should in some other > method call SetComplete so the transaction can complete and the object > can be deactivated. In general this design can cause problems if the > object is not used correctly by clients so I try to avoid designs that > rely on the client doing the right thing. > [Ron Jacobs]
A question Ron (or any one else): Under what condition will the transaction commit or abort if the base client creates a COM+ transactional object and only ever calls one method which calls either EnableCommit (or nothing since this is the default) or DisableCommit? i.e. It never calls SetComplete or SetAbort. Does the transaction commit or abort when the base client releases its reference? I must admit I've always tended to make one big method call per transaction with either SetComplete or SetAbort. I find it easier to manage (even if some would call it un-OO). Alan, do you need to pass all this state? Can you not use construction strings? If several places use the same information it can be worth putting this in a separate COM+ object so you only need to put the construction string in one place. The minor performance hit is worth it compared to the lowered administration burden. Peter Foreman __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
