Ensure single instance of Java application

807580

Hi,

I'd like to make sure that only one instance of my Java application can be run and I've done some search around. The recommended approach seems to be using ServerSocket that occupies a certain port.

On the other hand I've seen that JConsole could display the names of all Java processes that are running. This is perhaps another approach to the issue? JConsole is said to be a pure Java tool, so I was wondering how this is implemented. I've googled a bit but still could not find out how. Could someone please give me a hint?

Thanks a lot!

gimbal2

You could take a look at the source code. This forum thread seems to indicate where to find it:

[http://forums.sun.com/thread.jspa?threadID=788974|http://forums.sun.com/thread.jspa?threadID=788974]

807580

SwordDevil wrote:
Hi,

I'd like to make sure that only one instance of my Java application can be run and I've done some search around. The recommended approach seems to be using ServerSocket that occupies a certain port.

On the other hand I've seen that JConsole could display the names of all Java processes that are running. This is perhaps another approach to the issue? JConsole is said to be a pure Java tool.

Not especially. How it finds local Java processes is primarily platform-specific, and messy. Or it uses JMX, if it can. That's a possibility, but I'm not seeing a clear advantage over the simple server socket approach.

807580

Use some kind of locking mechanism. This method uses a simple lock on a file and cleans up behind itself reliably and works across all platforms...

private static boolean lockInstance(final String lockFile) {
try {
final File file = new File(lockFile);
final RandomAccessFile randomAccessFile = new RandomAccessFile(file, "rw");
final FileLock fileLock = randomAccessFile.getChannel().tryLock();
if (fileLock != null) {
Runtime.getRuntime().addShutdownHook(new Thread() {
public void run() {
try {
fileLock.release();
randomAccessFile.close();
file.delete();
} catch (Exception e) {
log.error("Unable to remove lock file: " + lockFile, e);
}
}
});
return true;
}
} catch (Exception e) {
log.error("Unable to create and/or lock file: " + lockFile, e);
}
return false;
}

Or if you can think of another locking mechanism through DB interaction, that would be equally effective as well.

807580

kilyas wrote:
Use some kind of locking mechanism. This method uses a simple lock on a file and cleans up behind itself reliably

Not in the case of a power cut.

807580

Using a ServerSocket is basically a one liner. It is the simplest approach IMHO.

807580

Does this lock mechanism work when e.g. the user kills the app using Task Manager? I've never tested this myself although some discussions say it may fail.

masijade

SwordDevil wrote:
Does this lock mechanism work when e.g. the user kills the app using Task Manager? I've never tested this myself although some discussions say it may fail.

So what, in your mind, is wrong with the ServerSocket approach? Why do all "newbies" immediately discard this approach and then go out and try all these other complex, unreliable, obscure, and/or otherwise questionable practices?

807580

ServerSocket seems to be a reliable approach, and it's simple, and I like it. I'm just curious how JConsole detects all running Java processes.

807580

SwordDevil wrote:
ServerSocket seems to be a reliable approach, and it's simple, and I like it. I'm just curious how JConsole detects all running Java processes.

I think one has to be careful in that "pure Java" != "platform independence" even though at first glance you might think otherwise. Some code could be "pure Java" in that it doesn't actually call any native code (directly) but it could still be platform dependent in doing things like for example examining process lists on an OS. Of course that code could also detect which OS and do the "right thing" for such activity based on that information but it's not completely platform independent in the "run anywhere" philosophy.

807580

SwordDevil wrote:
ServerSocket seems to be a reliable approach, and it's simple, and I like it. I'm just curious how JConsole detects all running Java processes.

It varies from platform to platform.