Mehrmaligen Start verhindern

[terryl]

Hallo,

ich möchte verhindern, dass mein Programm mehrmals gestartet werden kann. (Bei wiederholtem Aufruf soll dann eine Messagebox oder so erscheinen). Im Internet habe ich den Hinweis auf die java.nio gefunden, erkenne aber nicht, wie sie mir helfen soll.

Das Problem möchte ich gerne im Code gelöst haben; es soll also nicht beim ersten Aufruf eine Datei oder sowas erstellt werden, auf deren Vorhandensein dann geprüft wird.

 

[The_S]

Guck mal hier

http://www.java-blog-buch.de/d-java-anwendung-nur-einmal-ausfuhren/

bzw. als Paket hier

http://just-my-2-cents.de/libraries.html

 

[stev.glasow]

http://www.java-blog-buch.de/d-java-anwendung-nur-einmal-ausfuhren/

ich würde dort noch f.deleteOnExit() setzen und und regelmäßig nen timestamp in die datei schreiben oder irgendwie mit lastModified() arbeiten, denn wenn jetzt dein program abschmiert wird die datei nicht gelöscht und du kannst es nicht mehr starten.
[edit]

Sollte Ihr Programm die Datei beim Beenden nicht mehr löschen können (Absturz der VM, Absturz des Betriebssystems, Stromausfall, …) kann Ihre Anwendung nicht mehr gestartet werden, bis die Lock-Datei manuell entfernt wurde.

ah jo bist schon selber drauf gekommen, aber lässt sich wie gesagt einfach mit nem timestamp lösen. wenn die datei existert und der timestamp nen bestimmtes alter überschrittet hat ist das programm vorher irgendwie flöten gegangen.
extra nen port dafür zu missbrauchen find ich nicht nötig und wüsste auf die schnelle jetzt auch keinen anwendungsfall wo mehrere instanzen des selben programmes miteinander kommunizieren sollen.

 

[The_S]

http://www.java-blog-buch.de/d-java-anwendung-nur-einmal-ausfuhren/

ich würde dort noch f.deleteOnExit() setzen und und regelmäßig nen timestamp in die datei schreiben oder irgendwie mit lastModified() arbeiten, denn wenn jetzt dein program abschmiert wird die datei nicht gelöscht und du kannst es nicht mehr starten.

Dir ist bewusst, dass das Kapitel über 4 Seiten geht, und wir uns dabei Schritt für Schritt an eine gute Lösung ranarbeiten ? Wie man das Problem über einen File-Lock lösen könnte, wird im Kapitel zwar angesprochen, aber nur als Grundlage verwendet, da diese Methode (wie du schon sagtest) diverse Probleme nach sich ziehen würde.

 

[Spacerat]

ich würde dort noch f.deleteOnExit() setzen und und regelmäßig nen timestamp in die datei schreiben oder irgendwie mit lastModified() arbeiten, denn wenn jetzt dein program abschmiert wird die datei nicht gelöscht und du kannst es nicht mehr starten.

Also doch 'ne Datei? Scheint wohl nicht anders möglich. Aber... wieso dann nicht die Datei behalten und Startzeit und Stopzeit protokollieren. Wenn man, während das Programm läuft, die Datei sperrt, indem man sie offen hält, ist auch nur eine Instanz möglich. Beim Programmstart muß lediglich die Startzeit mit der Stopzeit verglichen werden. Ich würd's so machen.

mfg Spacerat

@Edit: Gut... vllt. doch mal vorher die Links eines Threads besuchen... Vergesst also meinen Kommentar... Tut was oben geschrieben wurde... Absolut genial sagimol.

 

[stev.glasow]

@Hobbi: ah jo. nich gesehen. naja wie gesagt, das ganze socket gedönste finde ich überflüssig.
@Spacerat: stimmt die datei offen halten wäre auch ne idee. aber wieso muss ich dann noch start und stopzeit prüfen? wenn die datei offen ist, läuft halt das program schon. mehr brauch ich doch gar nicht wissen. und wenn das program abschmiert wird die datei ja vom os geschlossen

 

[terryl]

@Hobbit_Im_Blutrausch: Eine Lock-Datei zu erstellen oder einen Port zu besetzen scheinen tatsächlich die einzigen Methoden zu sein. Offenbar besitzt Java keine (wenn auch versteckte) Methode festzustellen, ob die gerade laufende Anwendung erneut gestartet wurde.

@stevg: Gute Idee bei Dateien. Was aber, wenn dem PC plötzlich der Strom fehlt? Dann könnte auch deleteOnExit() nicht helfen und die Datei bleibt beim Neustart bestehen. Mir ist deshalb die Idee mit dem Port sympathischer, denn mit dem Beenden der VM oder dem Neustart des PCs ist dieser lokale Port wieder frei.

Danke euch beiden!

 

[stev.glasow]

nur gucken ob die datei existiert reicht auch nicht. würd halt mit nem timestamp arbeiten, alle paar sekunden in die datei schreiben und bei start prüfen wie lange der letzte zugriff her ist. und wenn dieser zu lange her ist das program starten.
oder halt die datei offen lassen - sprich nicht f.close() machen. und mein start prüfen ob du zugriff auf die datei hast. wenn nicht läuft noch ne andere instanz. das problem mit dem abschmieren wäre halt auch gelöst weil das os die datei schließt wenn dein programm incl vm abstürzt.
[edit]
meist ist das aber eh nicht der fall, meist hast du doch enifach nur ne java exception und dann kannst du die datei ja immer noch schließen/löschen/whatever

 

[The_S]

wenn die datei existert und der timestamp nen bestimmtes alter überschrittet hat ist das programm vorher irgendwie flöten gegangen

Aber bis dieser Zeitraum nicht überschritten wurde, lässt sich das Programm nicht mehr starten. Außerdem gibt es z. B. auch Serverprogramme, die Tage, Wochen, Monate, Jahre, ... am Stück laufen sollen.

wüsste auf die schnelle jetzt auch keinen anwendungsfall wo mehrere instanzen des selben programmes miteinander kommunizieren sollen.

Ich hab mal nen mp3-player programmiert. Den mp3-Player hab ich mit meinen .mp3-Dateien verknüpft. Wenn jetzt doppelte auf ne mp3-Datei geklickt wurde, wurde jedesmal der Player gestartet und die mp3-Datei wiedergeben - was zur Überlagerung von mehreren Liedern geführt hat.

Durch oben vorgestellte Methode hab ich zum Einen realisiert, dass der Mp3-Player nur einmal gestartet werden konnte, und zum Anderen, dass die zweite Instanz das ausgewählte Lied der ersten Instanz übergeben konnte. So gibt es immer nur eine Instanz und wenn ein mp3-Datei per Doppelklick abgespielt werden soll, nimmt diese 1. Instanz das mp3-File in die Wiedergabeliste mit auf bzw. gibt Sie (je nach Konfiguration) direkt wieder.

@Spacerat

liest eigetnlich wer meine Links?

 

[The_S]

nur gucken ob die datei existiert reicht auch nicht. würd halt mit nem timestamp arbeiten, alle paar sekunden in die datei schreiben und bei start prüfen wie lange der letzte zugriff her ist. und wenn dieser zu lange her ist das program starten.

Und wenn das Programm mal n paar Tage gelaufen ist, haste ne rießige Datei voll mit Timestamps ...

btw: Crosspost (sind hier nicht so gerne gesehen): http://www.tutorials.de/forum/java/331395-mehrmaligen-start-verhindern.html#post1711936

 

[L-ectron-X]

Auch die allgemeinen Forumregeln wurden verletzt. Es gibt mehr als eine Hand voll Beiträge zu diesem Thema im Forum. Bitte Forumsuche benutzen!

 

[Spacerat]

@Hobbit: Jaaahhaa.. Hab' oben schon editiert. Ahnt ja keiner das Ihr so schnell seid.

Finally... Eine Möglichkeit fällt mir da doch noch ein... Ist aber recht unsauber und Betriebssystem-Abhängig. Sie führt über "Runtime.Exec()" zu den jeweiligen Programm-Managern. Bitte kein Kommentar...

mfg Spacerat

 

[stev.glasow]

nur gucken ob die datei existiert reicht auch nicht. würd halt mit nem timestamp arbeiten, alle paar sekunden in die datei schreiben und bei start prüfen wie lange der letzte zugriff her ist. und wenn dieser zu lange her ist das program starten.

Und wenn das Programm mal n paar Tage gelaufen ist, haste ne rießige Datei voll mit Timestamps ...

ne, die alten brauchst du ja nicht, immer nur den letzten. eigentlich brauchst du da auch gar keine timestamps weil der letzte zugriff auf die datei vom dateisystem gespeichert wird. und das mit dem mp3 player kriegst du auch mit ner named pipi hin. aber passt schon, wer mit dateien schnöseln will soll schnöseln und wer nen socket missbrauchen will soll missbrauchen.

 

[The_S]

@stevg

na, passt nicht. Wenn sich sowas sauber auch nur über Dateien lösen lässt, dann würd ich das gerne wissen .

Wann wird denn lastModified aktualisiert? Beim Schließen oder beim Öffnen des Streams? Oder sogar, wenn der Stream nur etwas in die Datei schreibt? Und ist das bei jedem Betriebssystem so? Unter gewissen Umständen brauchst du dann aber auch wieder n Timestamp, nämlich dann, wenn lastModified bei min. einem Betriebssystem nicht mit dem Output eines Streams aktualisiert wird.

ne, die alten brauchst du ja nicht, immer nur den letzten.

Und wie löschst du den Inhalt einer Datei und ersetzt ihn durch einen neuen, ohne die Datei (wenn auch nur minimal kurz) zu schließen bzw. zu löschen?

@Spacerat

war ja net böse gemeint

 

[Illuvatar]

Ich hab eben einen Kommentar in Hobbits Blog geschrieben, aber da der Beitrag noch auf Moderation wartet, schreib ich das hier auch noch mal

Eine kleine Anmerkung zur FileLock-Methode: Seit Java NIO gibt es die Möglichkeit, “echte” File-Locks zu realisieren. Hierzu wird die Methode FileChannel#tryLock verwendet.

Dadurch fallen ein Großteil der Nachteile weg. Eine Kommunikation ist allerdings immer noch nicht möglich. Solch ein FileLock wird aber eben automatisch aufgehoben sobald das Programm nicht mehr läuft. Das wichtige Kriterium wäre nicht mehr, ob die Datei existiert, sondern ob tryLock ein FileLock oder null zurückgibt. Ob die Datei noch existiert, kann dafür als Kriterium verwendet werden, ob das Programm sauber beendet wurde.

 

[The_S]

freigeschalten und beantwortet

 

[Illuvatar]

Hmm... ich will jetzt nicht da die Kommentare zuspammen, aber es interessiert mich doch
Was ist denn da so systemspezifisch? Das einzige was in der Java API steht ist, dass es nicht auf allen Systemen shared locks gibt. Ich weiß zwar nicht wirklich was das ist, glaube aber dass man die nicht braucht

 

[The_S]

Sehr viel passieren kann natürlich nicht, aber wenn man die einzelnen Punkte, wie z. B., ...

... dass die Klasse FileLock einen extra Abschnitt in der Doku hat, der "Platform dependencies" heißt.
... dass die konkreten Implementierungen von FileLock und FileChannel in den sun-packages ausgelagert wurden
... und dass in der Doku Ausschnitte wie z. B.

Whether or not a lock actually prevents another program from accessing the content of the locked region is system-dependent and therefore unspecified

On some systems, closing a channel releases all locks held by the Java virtual machine on the underlying file regardless of whether the locks were acquired via that channel or via another channel open on the same file.

Some network filesystems permit file locking to be used with memory-mapped files only when the locked regions are page-aligned and a whole multiple of the underlying hardware's page size. Some network filesystems do not implement file locks on regions that extend past a certain position, often 230 or 231. In general, great care should be taken when locking files that reside on network filesystems.

zusammen betrachtet, komme ich persönlich zu dem Schluss, dass da etwas weitaus komplexeres dahinterliegt, als man eigentlich denkt und somit auch "spezialfallanfällig" ist.

Natürlich (bzw. ich geh davon einfach mal aus) funktioniert die Methode bei 99% der Anwendungsfälle wohl ohne Probleme. Aber ich möchte unsere Leser (die größtenteils wohl noch nicht so übermäßig erfahren sind) eigentlich nicht mit solchen Überlegungen konfrontieren, weshalb ich auf die FileLock-Methode bis jetzt verzichtet habe.

btw: Kommentare sind bei uns immer gerne gesehen, nur keine Scheu

 

[terryl]

@L-ectron-X: Mag ja sein, dass das Thema im Forum schon mehrfach behandelt wurde. Um im Forum die Suchergebnisse auf ein erträgliches Maß zu reduzieren, muss man aber schon wissen, nach welchen Begriffen man suchen muss. Bei meinen Versuchen mit unterschiedlichen Wörtern bekam ich mal 6000 Ergebnisse -- für mich ein wenig zu viel zum Stöbern nach der Antwort ...

 

[stev.glasow]

@stevg

na, passt nicht. Wenn sich sowas sauber auch nur über Dateien lösen lässt, dann würd ich das gerne wissen .

Wann wird denn lastModified aktualisiert? Beim Schließen oder beim Öffnen des Streams? Oder sogar, wenn der Stream nur etwas in die Datei schreibt? Und ist das bei jedem Betriebssystem so? Unter gewissen Umständen brauchst du dann aber auch wieder n Timestamp, nämlich dann, wenn lastModified bei min. einem Betriebssystem nicht mit dem Output eines Streams aktualisiert wird.

ne, die alten brauchst du ja nicht, immer nur den letzten.

Und wie löschst du den Inhalt einer Datei und ersetzt ihn durch einen neuen, ohne die Datei (wenn auch nur minimal kurz) zu schließen bzw. zu löschen?

mit RandomAccessFile kannst so solchen schweinskram machen, damit können sogar 2 verschiedenen programme auf der gleichen datei lesen und schreiben, womit sich dann relativ leicht ne pipe bauen lässt über die man kommunizieren kann. ich hab ehrlich gesagt keine ahnung wie RandomAccessFile das intern händelt, ist mir auch egal, selbst wenn er die datei ständig aufmacht und schließt. bei java geht sone kommunikation halt über RandomAccessFile und bei winapi gibts eh schon direkt fertige named pipes, das reicht mir von prinzip dann auch.
[edit]
oh man der thread hat ja 2 seiten - ganze nacht nicht gepennt. ich hau mich mal hin.