COMments

[Previous] [Next]

The Singleton design pattern will always work between Visual Basic clients and servers. However, it has the potential to fail miserably when used with non-Visual Basic clients. COM threading apartment models are to blame for this failure. (See Chapter 3.) In short, publicly defined variables in Visual Basic modules are globally accessible to all instances of classes declared within the same project. Therefore, the Singleton is enforceable, or so it seems. It's more accurate to say that publicly defined variables in Visual Basic modules are globally accessible to all instances of classes declared within the same project that reside in the same COM apartment. It is therefore possible for two instances of CalcFactory to exist in different COM apartments, which results in unique instances of the Calculator class existing in each apartment.

To guarantee compliance of the Singleton implementation in a Visual Basic-generated ActiveX DLL, set the Threading Model option of the DLL to Single Threaded on the General tab of the Project Properties dialog box. (See Figure 10-3.) This forces all instances of classes defined in this DLL to exist in the same COM apartment. However, if the client is multithreaded, all requests to the Calculator object will be marshaled across thread boundaries via a proxy. The price you pay in this scenario is performance, and the price can be huge. If performance becomes an issue, avoid the Singleton implementation.

Figure 10-3. Set the Threading Model option to Single Threaded.