September 2005 - Posts
Normally, if you would like a singleton implementation of a class, you would go about it a little bit like this:
public class BloggingAbout
{
private static BloggingAbout bloggingAbout;
private BloggingAbout()
{
}
public static BloggingAbout BloggingAboutInstance
{
get
{
if (bloggingAbout == null)
{
bloggingAbout = new BloggingAbout();
}
return bloggingAbout;
}
}
}
The trouble here is that this implementation is not thread safe. The reason I post this is I recently ran into some code of an old colleague of mine (from my former employee) and some tests showed his singleton class was instantiated several times when the application was stressed with requests from the start, which caused unwanted lag in the application. Apparently him not implementing the Singleton pattern thread safe caused this, so I fixed it.
It's not thread safe because two different threads could both evaluate if (bloggingAbout == null) and find it to be true and create an instance, which violates the singleton pattern. To make sure this doesn't happen, you could use locking which would result in this code:
public class BloggingAbout
{
private static BloggingAbout bloggingAbout;
private static object lockObject = new object();
private BloggingAbout()
{
}
public static BloggingAbout BloggingAboutInstance
{
get
{
lock(lockObject)
{
if (bloggingAbout == null)
{
bloggingAbout = new BloggingAbout();
}
return bloggingAbout;
}
}
}
}
The lock statement ensures that one thread does not enter a critical section of code while another thread is in that critical section. If another thread attempts to enter a locked section of code, it will wait (block) until the object is released. This is the reason the lockObject has to exist even before calling the static property BloggingAboutInstance.
At my current project, I’m trying to bring some structure in our visual Studio projects. But I’m finding myself not sure about how far I should go. Maybe you should know I tend to be something of a purist. At the moment, we created a project with a single class, because it didn’t belong anywhere else. So we created a client specific ‘Common’ project and put the one file there.
On one hand it is how it should be: the file had nothing to do in any of the other projects, so it should be in a separate project. On the other: it’s about one file! A class with only four properties. Isn’t it some kind of overkill putting it in a separate project?
I think this is the way it should be, mostly because things should be where they need to be, not where they end up because of developer laziness or something like that. And besides, other classes will probably follow soon. People might think putting a single (simple) class in a separate project is one step too far…
I’m curious what you guys think. Drop me a line in the comments.
I couldn't come up with a decent title for this post, so I just spit out some keywords.
We got an error today, stating the Controller of some object we wanted to put on CallContext needed to be serializable. Not thinking about the weird content of this error, we tried what would happen if we made the controller serializable. We now got a different error, which was even more weird:
Unhandled Exception: System.Security.SecurityException:
Type System.DelegateSerializationHolder and the types derived from it (such as System.DelegateSerializationHolder) are not permitted to be deserialized at this security level.
This error occured when I tried to put some object on the CallContext by calling CallContext.SetData. We remembered the controller needing to be serializable, while it wasn't remoted or anything. After some investigation, I found the problem. When you put an object on CallContext, be sure it doesn't have any other objects attached to it through events. Because these events kind of 'bind' the objects together, so the object which subscribed to the event is sent also! We implemented ICloneable and put the clone on the CallContext: this solved the problem.
Oh yeah: MemberwiseClone copies the events and their handlers also. So this is NOT the way to implement the Clone() method. You will have to set each property individually on a new instantiation of the class. We're working on a reflection-implementation which will take away the need to copy each property individually in code, but to let a method do this for you. If this turns out to be interesting, I'll post it here.
I saw a presentation monday to explain the basics of .Net to some starting developers. In that presentation, I saw a piece of code design I don't think should be showed. Ever. Especially to people who are about to enter the .Net world. In one cs-file, I saw a base class, two inheriting classes and then again two classes which inherited from on of the former mentioned classes. So there were 5 public classes in one file. A shiver ran down my back ...
The internal Microsoft Codeing Guidelines I blogged about earlier clearly state: 'Source files should contain only one public type' and I strongly agree. If you need some internal classes, that's fine. But multiple public classes in one file? That's not done... At least, I think so. What do you think?
For my current project I'm trying to implement a factory pattern using remoting. This seems to be more difficult than I imagined. I've done the following:
- Create an Interfaces project containing an IProductFactory and an IProduct.
- Create a Class Library which implements Product and ProductFactory and is hosted in IIS through a web.config.
- Create a project which makes a ProductFactory and uses this to create a product, all based on the interfaces.
Everything seems to be ok: the ProductFactory is instantiated perfect, and properties and methods with 'normal' returntypes can be accessed, untill I try to use the ProductFactory to create a Product. I receive a message stating there is "No assembly associated with XML key". In that same message, there's a link to the key (I guess) starting with "http://schemas.microsoft.com/clr/nsassem/". I tried to set TypeFilterLevel to "Full" but that didn't solve anything. I'll try to find an answer, and when I do I will keep you posted. If you have any idea, will you drop me a line?
P.S. writing my own (de)serilization seems to do the trick, but I would like to do without that...
Edit: apparently, classes which are instantiated by remoted classes, have to inherit MarshalByRefObject because they are remoted also. This means not the entire object is sent over the line, but only the interface. And that means that every call to a property or a method goes to the server component in stead of happening on the client. This kind of 'chatty' interface is not what I intended. As a solution, I'll probably use the Updater Application Block to keep all the clients in sync with the objects on the server automaticaly.