Have each process "register" in a table set aside for that purpose. As each process completes, the last thing it does is "unregister". Last process to finish shuts down the database.
Just a thought. Donald On Fri, May 21, 2010 at 5:07 PM, Kathey Marsden <[email protected]> wrote: > I hope this doesn't give anyone else similar ideas, but I need some advice > :-) > > I am trying to help the developers of a Java API that uses a Derby > database to hold centralized information specific to a machine. > The API gets invoked when products are being installed or upgraded on the > machine and records product information, versions, dependencies, etc, but > otherwise they don't want it to run. > > They have a requirement for multiple jvm access, primarily for nested > installs where one product installation accesses the database and needs to > launch a child process to install another product. Their implementation > starts network server on-demand if it is not started already and then > connects with the client driver. Additional processes that come in will > check and find network server running elsewhere so will just connect to the > already the started server. They think the "parent" process will always > come in first, so there is not a risk of one process bringing network server > down in the middle of someone else's work. > > This all seems very fragile to me and is a new and untested configuration, > but I am having trouble coming up with a good design suggestion. They at > one time tried a service but do not want the full time overhead of a server > running and don't want to require root access to start the service. > > Any other ideas? > > Thanks > > Kathey > > > > -- Family photographs are a critical legacy for ourselves and our descendants. Protect that legacy with a digital backup and recovery plan. Join the photo preservation advocacy Facebook group: http://www.facebook.com/home.php?ref=logo#/group.php?gid=148274709288
