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