Til sidst lykkedes det mig at få det til at virke, men med nogle ændringer. Ideen er at bruge LockModeType.PESSIMISTIC_FORCE_INCREMENT i stedet for PESSIMISTIC_WRITE. Ved at bruge denne låsetilstand opfører Cron Jobs sig som følger:
- Når det første job gør valget til opdatering går alt som forventet, men versionen på objektet ændres.
- Hvis et andet job forsøger at foretage det samme valg, mens det første stadig er i sin transaktion, lancerer JPA en OptimisticLockException, så hvis du fanger den undtagelse, kan du være sikker på, at den blev kastet for en læselås.
Denne løsning har forskellige modstykker:
- SynchronizedCronJobTask skal have et versionsfelt og være under versionskontrol med @Version
- Du skal håndtere OptimisticLockException, og det bør være catch uden for transaktionsservicemetoden for at foretage tilbagerulning, når delock sker.
- IMHO er en ikke-elegant løsning, meget værre end blot en lås, hvor Cron Jobs venter på, at de tidligere Jobs er færdige.