Argh! Well, it turns out that the real problem was that when creating a mutex for a module-level singleton you should not store a ref to the handle in an instance that might find itself getting popped. Assign to a class variable that will stick. D'oh!
I will take a look at setting up the COM object as a service. One question that pops up is whether such a service would run "as the local user"? We use the COM service as an authentication bridge between an agent service that is always running in the background (but runs as the admin) and various users on the system. Hmmm, something to check out. Jim On Wed, 02 Feb 2005 15:11:28 -0600, Jens B. Jorgensen <[EMAIL PROTECTED]> wrote: > This is indeed an interesting thing do to. The 'right' way to create a > singleton COM object is probably to run an NT Service that hosts the COM > object. The COM Service Control Manager decides when to spin up new > processes for LocalServer32 server object creation requests. You need a > process to be already running and have registered the class object with > the SCM. I'm not sure how to do this correctly in Python as I've only > done this in C++. To get a better understanding of how this stuff works > I'd recommend you take a look at Don Box's book Essential COM. > > I'm not sure what you were doing with the Mutex and file locking but I'm > guessing all that stuff would not help since it is only getting called > after the important part has happened: after the SCM has already decided > to spin up a new a new process. But then again if process is already > running and has registered the class object then you'd think the SCM > would just forward the request to you. > > Sorry I can't be more help than this. I've done this same kind of thing > before, but only in c++. > > Jim McCoy wrote: > > >I am having a very difficult time enforcing a single running instance > >of a COM server and am hoping that someone out there might have a > >suggestion. The basic scenario is that we have a COM server (created > >with the assistance of win32com.server) which needs to perform a > >somewhat laborious data loading process when started. The problem is > >that a dll which makes calls to this COM server was spawning off a new > >server every time it called in a query. We eliminated part of the > >crushing burden of constantly spawned COM server instances by moving > >the heavy lifting into a singleton (the simple module-level singleton > >pattern) and having each COM server attach to this singleton. This > >solved our first problem with the start-up load but we still end up > >with way to many instances of our proxy to this singleton being > >created and wanted to figure out a way to make sure that only a single > >instance of this proxy was created. > > > >So,l first tried using the standard CreateMutex recipe to ensure that > >only one instance of the COM server would be created. Unfortunately > >this particular process works fine when I run a test script from the > >command line but the COM server is able to blow right by any attempts > >to use the mutex to limit the number of copies that are running. > > > >Next up was an attempt to create a lockfile. Same end-result, nothing > >seemed to stop the COM servers from each grabbing what was thought to > >be an exclusive lock. > > > >At this point I have run out of ideas. Does anyone have a suggestion > >of how to create a COM server in Python that can ensure that only a > >single instance of the COM server is running? > > > >Regards, > > > >Jim > >_______________________________________________ > >Python-win32 mailing list > >[email protected] > >http://mail.python.org/mailman/listinfo/python-win32 > > > > > > -- > Jens B. Jorgensen > [EMAIL PROTECTED] > > "With a focused commitment to our clients and our people, we deliver value > through customized technology solutions" > > > _______________________________________________ Python-win32 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-win32
