marcus/pdf-umbenenner
1
0
Fork 0
Code Issues 14 Releases 2 Activity

Bugfix V3.2: RunLockPort-JavaDoc korrigiert und Backup-Fehler bei aktivem Scheduler behoben

Browse Source 
BUG 1: RunLockPort-JavaDoc dokumentierte den Scheduler-Tick faelschlicherweise als
nicht-blockierenden Pfad mit tryAcquire(). Da execute() intern acquire() aufruft,
wuerde tryAcquire() vor execute() einen Double-Lock erzeugen. JavaDoc korrigiert:
Scheduler-Tick nutzt denselben blockierenden acquire()-Pfad wie der manuelle Lauf.

BUG 2: GuiConfigurationPropertiesWriter.copyFile() faengt jetzt AccessDeniedException
separat ab und liefert den klaren Hinweis "Konfiguration kann nicht gespeichert
werden - Scheduler laeuft." statt einer generischen Fehlermeldung.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Marcus van Elst
2026-05-07 12:14:43 +02:00
parent 4bc70dae75
commit 719cc50d16
2 changed files with 11 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/port/out/RunLockPort.java
+7 -7
View File
@@ -16,18 +16,18 @@ import java.util.Optional;
* <li>Kontrollierten Startabbruch ermöglichen, wenn bereits eine Instanz läuft</li>
* </ul>
* <p>
* Lock-Lifecycle (blockierender Pfad – headless und manueller GUI-Lauf):
* Lock-Lifecycle (blockierender Pfad – headless, manueller GUI-Lauf und Scheduler-Tick):
* <ol>
* <li>Lock beim Laufstart erwerben ({@link #acquire()})</li>
* <li>Lock für die gesamte Dauer des Laufs halten</li>
* <li>Lock am Laufende freigeben ({@link #release()}), auch bei Fehler</li>
* </ol>
* Lock-Lifecycle (nicht-blockierender Pfad – Scheduler-Tick):
* <ol>
* <li>Lock nicht-blockierend versuchen ({@link #tryAcquire()})</li>
* <li>Bei leerem Optional sofort mit {@code SkippedBusy} abbrechen</li>
* <li>Bei vorhandenem Handle in try-with-resources verwenden</li>
* </ol>
* Der Scheduler-Tick verwendet dieselbe blockierende Methode {@link #acquire()} wie
* der manuelle Laufpfad. {@link BatchRunProcessingUseCase#execute execute()} ruft
* {@link #acquire()} intern auf; das Ergebnis {@code LOCK_UNAVAILABLE} signalisiert
* dem Aufrufer, dass ein paralleler Lauf aktiv ist.
* {@link #tryAcquire()} ist für Aufrufer vorgesehen, die außerhalb des Use-Case
* einen schnellen, nicht-blockierenden Lock-Versuch benötigen.
*/
public interface RunLockPort {