Hi, On the "registration" table approach, if someone closed their laptop of killed the child installer, when the database came back up it would see a table full of processes that didn't exist anymore. So when the first installer boots the database, it needs to delete the contents of the "registration" table. Better yet, make this "registration" table hold some useful install history. You can have a "status" column. When an installer inserts a row, it writes the start time into a TIMESTAMP column, and it writes "STARTING" into a column for holding status info. So if you are the first to boot the database and you see "STARTING" in the status column for a given row, you know that the given installer never finished, so you can change the status to "ABORTED" or "FAILED".
Anyway, I really just made this post so I could have an excuse to say "choose your form". ...I assume "full roaming vapor" *was* a Ghost Busters reference. Ha! -- http://nextdb.net - RESTful Relational Database http://www.nextdb.net/wiki/en/REST --- On Fri, 5/21/10, Donald McLean <[email protected]> wrote: From: Donald McLean <[email protected]> Subject: Re: Full roaming vapor embedded server To: "Derby Discussion" <[email protected]> Date: Friday, May 21, 2010, 4:58 PM 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
