Endlich habe ich es geschafft, dass es funktioniert, aber mit einigen Modifikationen. Die Idee ist, LockModeType.PESSIMISTIC_FORCE_INCREMENT anstelle von PESSIMISTIC_WRITE zu verwenden. Mit diesem Sperrmodus verhalten sich die Cron-Jobs wie folgt:
- Wenn der erste Job die Auswahl für die Aktualisierung trifft, läuft alles wie erwartet, aber die Version auf dem Objekt ändert sich.
- Wenn ein anderer Job versucht, dieselbe Auswahl zu treffen, während der erste noch in seiner Transaktion ist, startet JPA eine OptimisticLockException, sodass Sie sicher sein können, dass sie für eine Lesesperre ausgelöst wurde, wenn Sie diese Ausnahme abfangen.
Diese Lösung hat verschiedene Gegenstücke:
- SynchronizedCronJobTask muss ein Versionsfeld haben und mit @Version unter Versionskontrolle stehen
- Sie müssen OptimisticLockException behandeln, und es sollte außerhalb der Transaktionsdienstmethode abgefangen werden, um ein Rollback durchzuführen, wenn die Sperre aufgehoben wird.
- IMHO ist eine nicht elegante Lösung, viel schlimmer als einfach eine Sperre, bei der die Cron-Jobs darauf warten, dass die vorherigen Jobs beendet werden.
