--- 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.

Reply via email to