Re: COM+ Singletons & instances ?
From: UAError (null_at_null.null)
Date: 11/24/04
- Next message: Patrice: "Re: screen resolution detection"
- Previous message: Klaus H. Probst: "Re: Executing a PERL script from ASP.NET appl."
- In reply to: Angelos Karantzalis: "Re: COM+ Singletons & instances ?"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 24 Nov 2004 13:18:05 -0500
"Angelos Karantzalis" <akarantzalis@yahoo.com> wrote:
>> >What I'd like to do, is a l w a y s have a single instance of
>> >MyDatabaseConnectionInfo in-memory.
>>
>> - What scope of memory?
>> - application domain?
>> - machine?
>
>ES App. Domain. or IIS App domain.
Nothing in .Net is supposed to run inside the IIS Process
(which is a high privilege system process) the ASP.NET
worker process (asp_wp.exe) is responsible for managing
ASP.NET applications and Web services. In (2003 Server) IIS
6.0 you have the option of multiple, separately configured
Worker processes.
As a library the ES component executes in the clients
process (which really belongs to the CLR not the client .NET
application)
As a server the ES component has its own process (usually
run by dllhost.exe IFAIK).
>
>> That means:
>> - there is only one MyDatabaseConnectionInfo Singleton in
>> the client's application domain.
>> - but every client app has its own instance of
>> MyDatabaseConnectionInfo - so there are as many instances as
>> there are clients.
>
>It's library app. IIS threads are considered different clients?
I presume you're talking about the worker process, not IIS.
The documentation is a bit fuzzy on that. MTS/COM+ was
developed before the notion of application domains, so its
always stated the library will run in the client process.
However the CLR or any .NET host will always run multiple
application domains in the same process - and I'm not clear
whether the CLR will manage a single copy of the library for
multiple application domains - somehow I doubt it - but I
don't know.
Given that the Run-time host will try to keep the memory of
the application domains seperate I suspect that you will
have multiple versions of your "Singleton" it there are
multiple application domains using it.
On the other hand
"COM+ Integration: How .NET Enterprise Services Can Help You
Build Distributed Applications"
http://msdn.microsoft.com/msdnmag/issues/01/10/complus/default.aspx
may suggest that runtime actually only keeps one copy of the
library around:
"First, calls to instances of classes that derive from
ServicedComponent are intercepted at COM+ context
boundaries. These objects are called context-bound. Calls to
instances of classes that do not derive from
ServicedComponent are not intercepted at COM+ context
boundaries. These objects are called context-agile. CLR
objects are always context-agile by default. They only
become context-bound when you derive from
ServicedComponent."
In any case, you would be safer to expose your "single
point" of access as a Windows Service and implement it as a
singleton remoting object (accessing it only locally of
course).
>What i need
>is a single instance serving a single IIS App.
If all instances of the app always run in the same worker
process AND the runtime host keeps only a single copy of the
ES component at hand, you should be fine - for now. If your
application runs on a multi-processor machine and separate
processors run different instances of the same app - then
you are going to end up with synchronization issues.
>>
>> >
>> >Issue 2:
>> >
>> > public class SecurityManager - it handles aythentication &
>> >authorisation, using dynamic class creation to create an
>> > adapter to a user datasource, be it LDAP, Active Directory, RDBMS or
>> >XML. This is a component that cries-out
>> > "re-use" and it will work for many of my projects. BUT ... if I
>include
>> >it on several COM+ Applications on the same
>> > machine, how can I specify from the client side which COM+
>Application
>> >I'm calling to ?
>>
>> If you are talking about two separate ES Apps rather than
>> two instances of the same ES app then that's easy - that is
>> what namespaces are for.
>>
>> // To foster reuse have all versions of SecurityManager
>> // implement the same IMySecurityManager Interface
>> using ServicedComponent1;
>> using ServicedComponent2:
>>
>> ...
>>
>> IMySecurityManager FirstSecMgr =
>> new ServicedComponent1.SecurityManager(
>> Parm11, Parm12, Parm13
>> );
>> IMySecurityManager SecondSecMgr =
>> new ServicedComponent2.SecurityManager(
>> Parm21, Parm22, Parm23, Parm24, Parm25
>> );
>
>.. but that's no re-use at all ... the code inside the SecurityManager
>implementation creates an "Adapter" object dynamically - from config data -
>to talk to LDAP, RDBMS etc. the core Security Manager code is always the
>same. I don't want to re-use an interface ... :? I want to have the same
>SecurityManager dll in seperate ES Apps, and pick the one I want to talk to.
>I can't believe that no-one has ever used the same dll in two separate ES
>Apps, so there must be a way :)
There are more levels of re-use than I would care to
count...and a lot of them include interfaces, especially if
you are trying to avoid God-Components, which you should at
all cost - so by your description I was imagining a unifying
interface that was implemented by different classes that may
share some subcomponents in their composition, and maybe
even an abstract superclass.
Anyway, I can't see where you see the problem. Each ES
component can use the same assembly. To expose the object to
the client simply provide a factory method on each ES
component.
>
>Cheers,
>Angel
>O:]
>
- Next message: Patrice: "Re: screen resolution detection"
- Previous message: Klaus H. Probst: "Re: Executing a PERL script from ASP.NET appl."
- In reply to: Angelos Karantzalis: "Re: COM+ Singletons & instances ?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
