Re: (CAY-227) Cannot launch modeler on OSX when logged in as user with networked home directory

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Tue Nov 02 2004 - 19:11:42 EST

  • Next message: Andriy Shapochka: "Re: (CAY-227) Cannot launch modeler on OSX when logged in as user with networked home directory"

    I wasn't thinking much about a preferences DB shared across the
    network. While the case in the bug report shows that this is possible
    in theory, it is probably very rare (not the network HOME dir, but the
    app started from different workstations pointing to this dir). So it is
    much more important to reliably support multiple instances of the
    modeler on the same machine.

    Originally I thought of a server running on one of the instances (if it
    shuts down, another instance can take over automagically - true p2p).
    Still there are other issues, so I agree with the main point of your
    post - doing this is just asking for trouble.

    So another solution might be a multi-window Modeler. Shouldn't be too
    hard to implement. When a Modeler starts, it sends a message out to see
    if the Modeler is already running on this machine (JavaGroups can help
    in instance discovery). If there is none, Modeler starts as usual. If
    there is another instance, it is activated (main window is brought to
    the front), and if there is a project to be opened, a new window is
    opened in that other JVM. I believe a lot of native desktop apps work
    like that.

    Another, simpler, fix for the current multi-instance problem is to
    allow prefs engine running in read-only mode. Secondary windows will
    use already stored preferences, but whenever a user pops a prefs
    dialog, we show a message that another instance locked the DB with
    options to override the lock (e.g. if the app has crashed), or close
    another app manually and retry. This will actually handle cross-machine
    db locking problem too.

    Andrus

    On Nov 2, 2004, at 11:56 AM, Gentry, Michael wrote:
    > Unfortunately, I don't think the lock file has enough information in it
    > (you'd need an IP address and port number) to make starting an HSQL
    > server useful. Unless, of course, you make your own lock file ...
    >
    > For example ...
    >
    > Client A (192.168.0.43) runs the modeler. No lock file exists. Great,
    > start a server!
    >
    > Client B (192.168.0.54) runs the modeler. Same user on a shared file
    > system. Lock file exists. Try connecting to the original Client A
    > started server. You'd need to know the IP and port number to change
    > the
    > connection dictionary so you could talk to client A's HSQLDB server.
    >
    > But wait, there is more! What if client A shuts down while client B is
    > still using its server? What if client A and B start battling over
    > preference settings (optimistic locking errors everywhere)? What port
    > number do you use? You could potentially have two Modelers running on
    > a
    > single system (different users) and they'd need different port numbers.
    > I'm sure I could dream up more scenarios ...
    >
    > I think the cleanest solution is to only allow access by one client at
    > a
    > time. Maybe capture the exception better to report it to the user.
    >
    > Just my thoughts ...
    >
    > /dev/mrg
    >



    This archive was generated by hypermail 2.0.0 : Tue Nov 02 2004 - 19:11:49 EST