This week's book giveaway is in the OCP forum.
We're giving away four copies of OCP Java SE 8 Programmer II Exam Study Guide and have Kathy Sierra, Bert Bates, & Elizabeth Robson on-line!
See this thread for details.
Win a copy of OCP Java SE 8 Programmer II Exam Study Guide this week in the OCP forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Only allow one instance of an App  RSS feed

 
Ranch Hand
Posts: 455
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was wondering if anyone could tell me how I go about
only allowing a user to have one instance of an application
open? We don't want them to be working in 2 different maintenance sessions, they should only have one session open.
I'd imagine whenever they clicked the button to open this app, I'd check to see if there was already an instance of it open, but I can't seem to find out exactly how to tell it to check.
Could someone help me out?

Thanks!
 
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A quick solution for this could be for you to keep an entry in a temp or your application's properties folder. Now, on the start-up you can either create a new file or add an entry into existing one, and also, not let the application start if there�s already an entry in the file (or the file itself).

Am sure there are better ways of doing this, but I don�t know them,.. yet!!

HTH!
 
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another way which is a bit easier to implement is to open a ServerSocket on a well-known port, just for the purpose of holding the port open; the second copy won't be allowed to listen on the same port. So main() might look like

 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is this a web app, or a standalone app, if its a web app, store the IP in application scope, otherwise, if its a standalone app, I'd agree with the file solution suggested earlier
 
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Isn't this exactly what the Singleton design pattern is for?

O'Reiily Singleton example
 
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


Isn't this exactly what the Singleton design pattern is for?


No. A singleton guarentees only one insantance of an object in a JVM. Jennifer Sohl needs one instance of an application running in one operating system. Using a singleton doesn't stop people running the app in another JVM instance on the same machine.
 
KR Campbell
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Paul Sturrock:

No. A singleton guarentees only one insantance of an object in a JVM. Jennifer Sohl needs one instance of an application running in one operating system. Using a singleton doesn't stop people running the app in another JVM instance on the same machine.



I see and learn, thank you.
 
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Deja vu cropping up again.
This was discussed several times in recent history, using the search function would have turned up a lot of data...
 
Ranch Hand
Posts: 1923
Linux Postgres Database Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
to add a small correction to my mentor efh


source: http://www.iana.org/assignments/port-numbers




Which are the benefits and drawbacks of both solutions?
For a file-lock, you need write-permissions to the filesystem.
How about opening a socket?
May it be influenced by a firewall?
If you use dynamic/ private ports, you're limited to 16384 locks (which seems to be a lot). But it's easier to loose the overview, if you use lots of locking apps (keep your 'services' up to date), compared with locking via filelock to the directory of installation, with the name of the application as unique identifier.

I guess in most cases you use locks to prevent the user from misbehaviour.
If the lock is used for security-issues (I cannot imagine an example at this moment) - a file-lock might be problematic, since it needs an absolute path in this case, leading to system-dependent questions.

More pros and cons?

[ May 19, 2004: Message edited by: Stefan Wagner ]
[ May 19, 2004: Message edited by: Stefan Wagner ]
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
major problem with file locks is what to do when (not if, it's bound to happen sooner rather than later) the program abends without removing the lockfile.
Now the user can not use the application again without you first telling him how to get around the lock mechanism.
He can now run as many instances as he wants by simply removing the lockfile whenever he wants (or if you're not careful just prevent the file from being written in the first place).
 
Stefan Wagner
Ranch Hand
Posts: 1923
Linux Postgres Database Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I talked about locking to help the user to avoid misbehaviour of the programm, not to fight against evil users, who try to damage their own system

I didn't specify some details in the example above, but may not edit that message, because it contains code and quote.


[ May 19, 2004: Message edited by: Stefan Wagner ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!