Singleton object problems 
Author Message
 Singleton object problems

  I have a singleton object that distribute event to registred
  clients. It works really great from VB in debug mode, but when
  I compile the COM, it does not stay singelton. All the clients
  get their own new instance of the COM.

  It is a single apartment thread, so the global data should not
  be a problem. Everything works fine when running in the de{*filter*}.

  Anyone had this problem?

  Pseudocode SERVER COM:
    Module modGlobal.mod
      contains a public ref to a CSingleton.cls
      sub main is entrypoint, creating the object.      

    Public Createable CConnection.cls
      returns a pointer to the public CSingelton

    Public NonCreateable CSingleton.cls
      contains a collection of interfaces i send global
      events to all clients at the same time.

  Pseudocode CLIENT COM:
    implements the IClient.cls, passed on to server when
    the instance of server is 'created' (singleton server).

Karl



Sat, 30 Aug 2003 17:19:19 GMT  
 Singleton object problems

Quote:

>  I have a singleton object that distribute event to registred
>  clients. It works really great from VB in debug mode, but when
>  I compile the COM, it does not stay singelton. All the clients
>  get their own new instance of the COM.

>  It is a single apartment thread, so the global data should not
>  be a problem. Everything works fine when running in the de{*filter*}.

You cannot do true Singletons in VB.  In the de{*filter*}, everything is running
in the de{*filter*} process--so it appears to work.  At runtime, each process
gets its own copy of the singleton.  In other words, you can only do
"process-wide" singletons in native VB.

Your immediate alternatives are:

  1. Determine if you can live with a "process-wide" singleton somehow.
  2. Use an ActiveX Exe coded as a single instance.
  3. Write a true singleton in some other language, VC++ perhaps.
  4. Explore other designs.

I suggest #4.  True singletons have a host of problems when crossing
processes, especially in network use.  Going with #3 is just going to spend
a lot of time to find other problems down the road.  One common alternative
design is to have multiple objects that share data (and are coded to handle
sequence issues).  This last option scales much better than a singleton, as
well.

Steven



Sun, 31 Aug 2003 00:32:43 GMT  
 Singleton object problems

  Thanks, I accually figured out that I had to run it in a proccess
  of its own last night. ActiveX.EXE helped me with that. Just as
  you propose, this is not good design.

  Although, this is just a test of mine, sharing global data over
  a mutltiple single thread aparments. Maybe I'm thinking wrong,
  so if you have a good solution for global data when threading
  in vb, please let me know.

  Using a singleton .exe will que all my requests from the threads.
  Or?

Karl

Quote:


> >  I have a singleton object that distribute event to registred
> >  clients. It works really great from VB in debug mode, but when
> >  I compile the COM, it does not stay singelton. All the clients
> >  get their own new instance of the COM.

> >  It is a single apartment thread, so the global data should not
> >  be a problem. Everything works fine when running in the de{*filter*}.

> You cannot do true Singletons in VB.  In the de{*filter*}, everything is running
> in the de{*filter*} process--so it appears to work.  At runtime, each process
> gets its own copy of the singleton.  In other words, you can only do
> "process-wide" singletons in native VB.

> Your immediate alternatives are:

>   1. Determine if you can live with a "process-wide" singleton somehow.
>   2. Use an ActiveX Exe coded as a single instance.
>   3. Write a true singleton in some other language, VC++ perhaps.
>   4. Explore other designs.

> I suggest #4.  True singletons have a host of problems when crossing
> processes, especially in network use.  Going with #3 is just going to spend
> a lot of time to find other problems down the road.  One common alternative
> design is to have multiple objects that share data (and are coded to handle
> sequence issues).  This last option scales much better than a singleton, as
> well.

> Steven



Sun, 31 Aug 2003 19:24:41 GMT  
 Singleton object problems
If you are using a DB, a simple solution is to let the locking of the DB
mostly handle the situation.  You create just a regular class, and each
process gets as many as it needs (or each process could get a process-wide
singleton).  So you have multiple copies of the data.  Now you take
advantage of the DB locking to code the class so that the data is always the
same at any given moment.  (This probably involves some kind of notification
process when data changes).

Steven

Quote:

>  Thanks, I accually figured out that I had to run it in a proccess
>  of its own last night. ActiveX.EXE helped me with that. Just as
>  you propose, this is not good design.

>  Although, this is just a test of mine, sharing global data over
>  a mutltiple single thread aparments. Maybe I'm thinking wrong,
>  so if you have a good solution for global data when threading
>  in vb, please let me know.

>  Using a singleton .exe will que all my requests from the threads.
>  Or?

>Karl



Mon, 01 Sep 2003 00:26:57 GMT  
 Singleton object problems


Fri, 19 Jun 1992 00:00:00 GMT  
 Singleton object problems

  Let me explain to you what is I try to accomplish. It's a test-project
of
  mine where I want to send events to many clients from a server. My
first
  (and working) solution was to make the 'singleton' object as described
  earlier. It contained a collection of client-interfaces I with ease
could
  loop and call the functions in the clients.

  The problem was when I started to think big-scale. What if I have 1000
  clients hooked on the server? First of all, it would be quite a load
on
  the singleton, and the que to access the STA would be awesome if I
looped
  through the interfaces to send an event to each and everyone of them.

  Codewise, this is just as far as I am now.

  My new thought is that I should create a new instance in a new thread
for
  every new connection and let the thread hold a pointer to the
interface.
  But since I'm not sure about the best way to let the threads know when
to
  send an event to the client, I'm here writing this.

  One way would be to have a singleton object with the global data; a
  collection of interfaces pointing to the threads and let this
singleton
  send events to the serverthreads. This will still be a syncronus call
  waiting for it to be ready, but it could be worked around with a
timer.

  [client]-[worker thread]-[singelton global data for threads]

  The thread has a pointer to the client. When thread is created, it add
  itself to a collection in the singelton. Now I thought of even one
more
  thing:

  [client]-[worker thread]-[singelton]-[event thread]

  I could create a new thread to send events. This would get rith of the
  problem with a new que is lined up to the singleton when events are
  beeing sent. It would be counter-productive to have the singeton cut
  of all the possitive from the threading.

  What do you say? Could it be sovled a better way? Is this a good way
  to solve it?

Karl

Quote:

> If you are using a DB, a simple solution is to let the locking of the DB
> mostly handle the situation.  You create just a regular class, and each
> process gets as many as it needs (or each process could get a process-wide
> singleton).  So you have multiple copies of the data.  Now you take
> advantage of the DB locking to code the class so that the data is always the
> same at any given moment.  (This probably involves some kind of notification
> process when data changes).

> Steven


> >  Thanks, I accually figured out that I had to run it in a proccess
> >  of its own last night. ActiveX.EXE helped me with that. Just as
> >  you propose, this is not good design.

> >  Although, this is just a test of mine, sharing global data over
> >  a mutltiple single thread aparments. Maybe I'm thinking wrong,
> >  so if you have a good solution for global data when threading
> >  in vb, please let me know.

> >  Using a singleton .exe will que all my requests from the threads.
> >  Or?

> >Karl



Mon, 01 Sep 2003 07:55:58 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Singleton not treated as singleton in VB

2. Singleton Objects in UserControl

3. Howto create a Singleton type of COM object with VisualBasic 6.0

4. Can an ActiveX DLL object be a singleton?

5. Make a VB ActiveX EXE as singleton object

6. Singleton Objects in UserControl

7. Make a VB ActiveX EXE as singleton object

8. Threading, timers and singleton....blocking problem

9. Singleton vs SingleCall Remoting

10. Class, singleton or module???

11. singleton class

12. singleton classes

 

 
Powered by phpBB® Forum Software