July 2004 - Posts
I added a new attribute to the SharpToolbox: [BuiltForMono].
If you know development tools or libraries that are built for Mono or compatible with Mono, let me know. I would add them to the list. If they are already in the list, I'd do the necessary fixing to add the new attribute.
Today only a few tools are flagged as Mono compatible.
I was playing with services and containers, as part of my implementation of Inversion of Control. All was fine until events came into play.
I needed to connect two services through events. Oh, all was working fine: there were no apparent troubles. But under the too calm surface sneaked a dreadful memory leak. Events don't play well with a loosely coupled environment by default. Better be warned.
This is related to the so-called "lapsed listener" problem.
Steve Maine has a good description of the problem. I'll copy-paste it here so I don't have to rephrase it:
The “lapsed listener” problem occurs when objects subscribe to events and subsequently fall out of scope. The problem is that the event subscriber doesn’t get garbage collected because the event is still holding a reference to it inside of the event’s invocation list. The event subscriber is still considered reachable from the GC’s point of view. As such, it doesn’t get collected until the event goes out of scope (which is usually at application shutdown) which means that the event subscriber is effectively “leaked”. Moral of the story: when you implement an Observer pattern, it’s important to consider the relative lifetime of events and subscribers. If implemented naively, you’ll end up having objects that live a lot longer than you think they should. Unsubscribe() is your friend.
Here is a small schema representing this:
In fact, .NET's delegates and events are implementations of the Observer Design Pattern. But the current problem is one more reminder that Design Patterns should not be applied blindly.
If you write the following code, you'll see that the object instance gets correctly released and collected:
StoopidObject object = new StoopidObject();
GC.Collect();
GC.WaitForPendingFinalizers();
If you write the following code instead, although there is no apparent reference kept to the Observer, the Observer instance will not be released:
Observer observer = new Observer();
Subject subject = new Subject();
subject.SomethingHappened += new EventHandler(observer.subject_SomethingHappened);
GC.Collect();
GC.WaitForPendingFinalizers();
Guys from around the community came with various solutions. They call them Weak Delegates. Follow the links to learn more:
I chose another way because the proposed solutions rely on weak references, and that is not satisfying in my case. With "weak delegates", the observers continue to receive events while not garbage collected. You never know when garbage collecting happens. If you base your developments on weak references, you have to accept the fact that your objects do not disappear immediately.
I want to prevent the notifications to be received by the observer as soon as it is meant to be disconnected. For that purpose, I ask the observer I'm going to remove to disconnect cleanly from its subjects. For simplicity, I use the Dispose method for this. This is because I know I'll call Dispose() each time I want to get rid of an object, this runs in a specific framework. Another method more explicit to the user could be used instead.
You can take a look at the source code I used for my tests.
Update: I show how to force disconnection in another post.
Update: I cover the same subject and much more in an article.
Dear Microsoft, we really need a date for .NET 2.0's "Go Live" license (and consequentely the beta 2). We need to know right now whether we should start developing with .NET 2.0 or whether it's too soon because we won't be allowed to deploy in production before next year or so.
If we don't have a date, there is no other option but keep developing new projects with 1.1 because we can't afford to postpone project releases. And that's bad because we'll have to recreate things that are in .NET 2.0, and dump a lot of code when .NET 2.0 is out.
So, please tell me, should I forget about .NET 2.0 right now, and not expect a "Go Live" license before December, November or so?
Clemens Vasters' post "Rows and Columns + Elements and Attributes is all you need" initiated an interesting discussion about the place of objects in SOA.
Does Object Oriented Programing fits with Service Orientation?
Read comments from Udi Dahan, Steve Eichert, and Jimmy Nilsson(1 and 2), for example.
In my opinion, the way to work with Entities, Managers, Objects and Services is still not clear. I haven't looked enough at architectures like ShadowFax or FABRIQ to know whether they contain guidance on this. My guess is that we'll have to wait some more time before best practices become clearly defined. Maybe all this is already well settled in the J2EE world?
I tend to do something similar to what Udi does. One of the open issues I see is "how to share business and validation rules between the Business layer and the Presentation layer?". If the rules are in the Managers, and not in the Entities, how do we use these rules in the Presentation layer?
Anyway, "encore un pavé dans la mare des tout-objet"...
Les inscriptions sont ouvertes, et le nombre de places et limité. Qu'on se le dise...
Rendez-vous en octobre.
The
lifecycle of Application, Page and Control in ASP.NET 2.0 is something you'll have to know and understand sooner or later. It is essential to put things where they belong, and this kind of information is not only for control writers. Jeff did a great work collecting it.
If you want to learn about this lifecycle in ASP.NET 1.1 instead, you can visit
this page.
I now have two CD ISO files to play with. Three to go to have the complete set...
http://msdn.microsoft.com/subscriptions/downloads/
Now I can't wait for... beta 2 and the "Go Live" license!
More Posts