Eindelijk is het me gelukt om het te laten werken, maar met enkele aanpassingen. Het idee is om LockModeType.PESSIMISTIC_FORCE_INCREMENT te gebruiken in plaats van PESSIMISTIC_WRITE. Bij gebruik van deze vergrendelingsmodus gedragen de Cron Jobs zich als volgt:
- Als de eerste taak de selectie voor update maakt, gaat alles zoals verwacht, maar de versie van het object verandert.
- Als een andere taak dezelfde selectie probeert te maken terwijl de eerste nog in de transactie is, lanceert JPA een OptimisticLockException, dus als u die uitzondering opvangt, kunt u er zeker van zijn dat deze werd gegenereerd voor een leesvergrendeling.
Deze oplossing heeft verschillende tegenhangers:
- SynchronizedCronJobTask moet een versieveld hebben en onder versiebeheer staan met @Version
- U moet OptimisticLockException afhandelen en het moet buiten de transactieservicemethode worden opgevangen om terugdraaien mogelijk te maken wanneer de vergrendeling plaatsvindt.
- IMHO is een niet-elegante oplossing, veel erger dan gewoon een slot waar de Cron Jobs wachten tot de vorige Jobs klaar zijn.