A quartz egy masszivan tulbonyolitott rendszer ahhoz kepest, amire tipikusan hasznaljak - tisztelet a kivetelnek, de semmit se lattam, amit a spring @schedule es a schedlock ne oldott volna meg tizedannyi komplexitasbol.
Abbol, amit irtal, azt tudom javasolni, vizsgald meg kozelebbrol, hogy mukodik az optimistic lock exception-t kezelo kod. hasonlot ugyanis lattam mar, ott az volt a gebasz, hogy a DBMS nem mindig ugyanazt a hibat adta, es a java + spring addig transformalgatta az exception-oket, hogy nem OptimisticLockingException lett a vegen, hanem valami egyeb.
A transaction isolation-t erdemes meg megnezni - esetfuggo, de a REPEATABLE_READ ugye egy tranzakcion belul ugyanazt adja vissza akkor is, ha a DB-ben mar megvaltozott a version... aztan meg commit-nal dob egy hatast. READ_COMMITTED a celszeru.
A program úgy látom nem arra lett készítve, hogy több alkalmazásszerveren dolgozzon és nem ekkora mennyiségű adat feldolgozására. Most csak a mókolás a megengedett. Nem szabad túl sok fejlesztést beleölni.
Nem bantani akarlak, de ennek alapjan en nem toltenek tobb idot azon a helyen a feltetlen szuksegesnel. Celszeru korbenezni, ennel csak jobbat fogsz talalni.