prüfen, ob ein "Job" noch läuft

[writeln]

Ich habe ein Programm entwickelt, dass Daten zwischen verschiedenen Datenbanken (ODBC) und / oder Outlook syncronisiert.
Das Programm wird über Job-Definitionen (Ini-Dateien) gesteuert. die jeweilige Jobdefinition wird beim Programmstart per Kommando-Parameter mitgegeben.
Zur Zeit schreibe ich an einem Scheduler, der die Jobs zeit-, bzw. ereignisgesteuert ausführt. Mehrere unterschiedliche Jobs dürfen dabei parallel laufen, jedoch nicht zwei gleiche Jobs.

Hier liegt der Knackpunkt:

Ich möchte feststellen,
1. ob die JobEXE läuft (ok, geht mit IsExeRunning, bzw. über die Windows Prozessliste)
2. ob ein bestimmter Job bereits ausgeführt wird (z.B. "adr_odbc2mapi")
der Job darf dann nicht doppelt ausgeführt werden.

Da die JobEXE auch noch manuell per Kommandozeile, bzw. per Desktop Verknüpfung gestartet werden kann, scheidet eine Prüfung per Jobtabelle aus.
Auch die Lösung, eine Logdatei zu schreiben, in die die JobEXEn laufend ihren Staus eintragen möchte ich vermeiden. Die Gefahr, dass Jobs sich bei Abstürzen nicht korrekt austragen ist mir zu groß.

Ich suche nach einer möglichst zuverlässigen Lösung, die auf der jeweiligen Maschine prüft, wie oft die JobEXE läuft und identifiziert, welche Jobs die einzelnen Instanzen gerade bearbeiten. Die Windows Jobliste scheint das nicht her zu geben.

Hat jemand eine Idee?

[nahpets]

Hallo,

per Mutex?

Mit IsExeRunning prüfen, ob das Programm läuft und/oder für jeden Job einen Mutex mit dem Jobnamen setzen bzw. prüfen, ob es den Mutex schon gibt und dann das Programm beenden oder mit anderem Job fortfahren oder wie immer der Arbeitsablauf aussehen mag.

[himitsu]

- registriere eine globale Windows-Message
- implementiere eine Nachrichtenbehandlung auf die Message,
welche auf Anfrage rausgibt, was das Programm macht
- finde die aktiven Instanzen deiner Anwendung
- frage über diese Message die anderen Instanzen, ob was sie abarbeiten und vergleiche es mit dem Job, welchen die Anwendung grad/gleich ausführen soll, wenn eine der anderen Anwendungen das Selbe macht, dann brich ab

[writeln]

Danke für die Lösungsvorschläge, beide klingen gut!

Mit Mutex Handles habe ich doch irgendwann schon mal was gemacht? :gruebel:

Mit Windows Messages habe ich noch nicht gearbeitet, klingt deutlich komplizierter.
Allerdings ließe sich damit nebenbei auch noch eine Kommunikation mit den Scheduler betreiben (Übermittlung der Job-Stati).
(Ich glaube, die Weihnachtstage sind gelaufen...) :wink:

Vielen Dank euch beiden!

[writeln]

Ok, die Mutex Lösung hat jetzt ca. 5 Mnuten in Anspruch genommen :-D

Delphi-Quellcode:

  public
    { Public-Deklarationen }
    // Formular Steuerung
    hMutex: THandle;
    CurrJobName: string;
    ...

procedure TFormCWSSrv.FormCreate(Sender: TObject);
begin
  // Formular vorbereiten und CurrJobName ermitteln
  ...

  // Mutex Prüfung
  hMutex := CreateMutex(NIL, True, PChar(CurrJobName));
   if (hMutex = 0) OR (GetLastError = ERROR_ALREADY_EXISTS) then
   begin
     CloseHandle(hMutex);
     halt;
  end
  else
    // Job zeitverzögert starten
    TimerJobStart.Enabled:= true;
end;

Die Lösung tut genau, was sie soll...
Windows Messages als Alternative werde ich mir aber trotzdem mal genau ansehen.

Nochmal Danke!

[himitsu]

Ist CurrJobName der Dateiname inkl. des kompletten Pfades?
Dieses wäre zumindestens besser, da man ja sonst leich gleich Namen für unterschiedliche Jobs haben kann.

[writeln]

CurrJobName beinhaltet tatsächlich nur den Namen des Jobs ("odbc2mapi", etc..).
Das reicht in meinem Falle aus, da die Jobdateien in einer fest definierten Verzeichnisstruktur liegen (<AppDir>\Settings\Jobs, <AppDir>\Settings\Logs, usw...).

Will man die Lösung allgemeiner nutzen, also mit beliebigen Speicherorten der Jobdefinitionen unter "Eigene Dokumente", oder ähnlich, müsste allerdings der ganze Datei-Pfad im Mutex angegeben werden.