Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Using Remote Object Models in .NET : Page 5

.NET supports two types of remote objects (by value and by reference) and three activation models for the later (client-activated, single call, and singleton). Each model and object type has its place. This article explains and contrasts the different models and when to apply them.


advertisement
Server-Activated Singleton
The Server-activated singleton activation model provides a single, well-known object to all clients. Because the clients connect to a single, well-known object, .NET ignores the client calls to new (to create a new instance), even if the singleton object is not created yet. (The .NET runtime in the client app domain has no way knowing what goes on in the host app domain anyway.) The singleton is created when the first client tries to access it. Subsequent client calls to create new objects and access attempts are all channeled to the same singleton object. Listing 2 demonstrates these points: You can see from the trace output that the constructor is only called once on the first access attempt, and that obj2 is wired to the same object as obj1.
The server-activated singleton activation model provides a single, well-known object to all clients.
Because the singleton constructor is only called implicitly by .NET under the covers, a singleton object cannot have parameterized constructors. Parameterized constructors are banned also because of an important semantic characteristic of the singleton activation model: At any given point in time, all clients share the same state of the singleton object (see Figure 4).

Figure 4: With a server-activated singleton object, all clients share the same well-known object.
If parameterized constructors were allowed then different clients could call them with different parameters and that would result in different states per client. If you try to create a singleton object using a parameterized constructor, .NET will throw an exception of type RemotingException. Using singleton objects
Singleton objects are the sworn enemy of scalability. There are only so many concurrent client calls a single object can sustain so you may choose to use them rarely. Make sure that the singleton will not be a hot spot for scalability and that your design will benefit from sharing the singleton's object state. In general, use a singleton object if it maps well to a true singleton in the application logic, such as a logbook that all components should log their activities to. Other examples include a single communication port, a single mechanical motor, etc. Avoid using a singleton if there is a chance that the business logic will allow more than one such object in the future, such as adding another motor, a second communication port, etc. The reason is clear: If your clients depend on implicitly being connected to the well-known object, and if more than one object is available, the clients would suddenly need to have a way to bind to the correct object. This could have severe implications on the application's programming model. Because of these limitations, I recommend that you avoid singletons in the general case and find ways of sharing the state of the singleton, instead of the singleton object itself. That said, there are cases where using a singleton is a good idea. For example, class factories are usually implemented as singletons.

Singleton object lifecycle
Once a singleton object is created it should live forever. That presents a problem to the .NET garbage collection mechanism—even if no client presently has a reference to the singleton object, the semantics of the singleton activation model stipulate that the singleton be kept alive so that future clients can connect to it and its state. .NET uses leasing to keep an object in a different process alive, but once the lease has expired, .NET will disconnect the singleton object from the remoting infrastructure and will eventually garbage collect it. When you work with singleton objects, you need to explicitly provide the singleton with a long enough (or even infinite) lease. A singleton object should not provide a deterministic mechanism to finalize its state, such as implementing IDisposable. If it is possible to deterministically dispose of a singleton object, it will present you with a problem: Once disposed of, the singleton object becomes useless. Furthermore, subsequent client attempts to access or create a new singleton will be channeled to the disposed object. A singleton by its very nature implies that it is acceptable to keep the object alive in memory for a long period of time, and therefore there is no need for deterministic finalization. A singleton object should only use a Finalize() method (the C# destructor).



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date