Ron\Steve Once again thanks for the input. The advice on overriding Activate\Deactivate is interesting.
I'll just briefly explain why I need this state and how I've come to this position. The state that I need in all my business/data objects includes a connection string, a database type (SQL Server or Oracle), a preferred language, a user guid, a trace flag. All objects use the same TYPE of info but the content varies depending on the user. This is why I can't use a generic construction string. Originally our objects used some session variables and a serialised, Web-cached configuration file. The IIS dependence of this design is obvious and whilst adding the COM+ support I thought I should take the opportunity to redesign the components to remove the IIS dependence as this could benefit us in future. I modified the classes to set properties with info passed in the New() constructor but then discovered that I couldn't do this in COM+. I now appreciate why thanks to these discussions. I now have an Init() method that sets the properties. It looks like I will have the Init() method call DisableCommit() and then call Init() prior to each business method call. The business method will SetComplete() or SetAbort(). The problem with passing all this info in each business method is that we have 400 stored procedures each wrapped by a data layer method and a business layer method and each method in those layers implements an interface. The method signatures for each interface, business and data method would need to be changed for 400 SPs. This is something I would rather not do at this stage. In future I may construct a class holding the info and pass that to each method as needed. Ironically this is what we thought of doing originally without spotting the COM+ implications. We wrote it off as poor design. Thanks again Alan -----Original Message----- From: Ron Jacobs [mailto:[EMAIL PROTECTED]] Sent: 19 April 2002 22:37 To: [EMAIL PROTECTED] Subject: Re: [DOTNET] Serviced Components and New() [EMAIL PROTECTED] [EMAIL PROTECTED] If the transaction is not resolved by SetComplete or SetAbort prior to the transaction timeout (1 minute by default) the transaction will timeout and abort. If the ServicedComponent is disposed prior to the timeout it will also abort. Ron Jacobs Program Manager XML Enterprise Services -----Original Message----- From: Peter Foreman [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 1:54 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] Serviced Components and New() --- 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. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
