[j2ee & Quartz] Problemen met JobStoreCMT

[Salandur]

Allereerst even de omgeving waarmee we hier werken en die hier voor problemen zorgen
- Weblogic Server 8.1 SP 4 geclusterd op 2 fysieke machines
- Oracle 8i(rac) ook geclusterd op 2 fysieke machines
- Connectionpools via de server (JNDI)
- Quartz 1.4.5 en 1.5.1

Als ik Quartz configureer om alles via de JobStoreTX op te slaan gaat het opstarten van Quartz goed, maar zodra ik JobStoreCMT gebruik blijft hij hangen bij het opstarten doordat het lijkt alsof er een connectie niet gesubmit wordt.
Bij de JobStoreCMT gebruiken we een volledig afgescheiden connection pools en datasources. Quartz wordt gestart via de meegeleverde QuartzInitializerServlet.

Heeft iemand hier eerder een soortgelijk probleem gehad en dat op kunnen lossen? Ik kan me voorstellen dat het opstarten niet goed als er via de servlet gestart wordt wegens het ontbreken van een transaction.

[ Voor 5% gewijzigd door Salandur op 10-11-2005 16:32 . Reden: quartzversies ]

[Stephan Oudmaijer]

Salandur schreef op donderdag 10 november 2005 @ 16:10:
Allereerst even de omgeving waarmee we hier werken en die hier voor problemen zorgen
- Weblogic Server 8.1 SP 4 geclusterd op 2 fysieke machines
- Oracle 8i(rac) ook geclusterd op 2 fysieke machines
- Connectionpools via de server (JNDI)

Als ik Quartz configureer om alles via de JobStoreTX op te slaan gaat het opstarten van Quartz goed, maar zodra ik JobStoreCMT gebruik blijft hij hangen bij het opstarten doordat het lijkt alsof er een connectie niet gesubmit wordt.
Bij de JobStoreCMT gebruiken we een volledig afgescheiden connection pools en datasources. Quartz wordt gestart via de meegeleverde QuartzInitializerServlet.

Heeft iemand hier eerder een soortgelijk probleem gehad en dat op kunnen lossen? Ik kan me voorstellen dat het opstarten niet goed als er via de servlet gestart wordt wegens het ontbreken van een transaction.

Moet je in je quartz.properties niet je JTA transaction manager specificeren? Ik zeg maar wat... deze ken je neem ik aan: http://www.opensymphony.c...cs/ConfigJobStoreCMT.html

[ Voor 5% gewijzigd door Stephan Oudmaijer op 10-11-2005 16:22 ]

[Salandur]

CK schreef op donderdag 10 november 2005 @ 16:19:
[...]
Moet je in je quartz.properties niet je JTA transaction manager specificeren? Ik zeg maar wat... deze ken je neem ik aan: http://www.opensymphony.c...cs/ConfigJobStoreCMT.html

Ik zal de 'txIsolationLevelSerializable' en 'txIsolationLevelReadCommitted' settings eens proberen te veranderen. Mss dat het helpt. Maar ik kende hem wel ja, maar daar kan je niet je JTA Transaction Manager specificeren, want dat is volgens mij altijd je server.

Voor de volledigheid even de database specifieke instellingen:

code:

org.quartz.jobStore.misfireThreshold = 15000
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreCMT
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.oracle.WebLogicOracleDelegate
org.quartz.jobStore.useProperties = false
org.quartz.jobStore.dataSource = managedDS
org.quartz.jobStore.nonManagedTXDataSource = nonManagedDS
org.quartz.jobStore.tablePrefix = QRTZ_
org.quartz.jobStore.isClustered = true
org.quartz.dataSource.managedDS.jndiURL = jdbc/quartz
org.quartz.dataSource.nonManagedDS.jndiURL = jdbc/quartz_nonmanaged

Verder zijn er per connectionpool 2 keer zoveel connecties als dat er quartz-threads op de server draaien aanwezig, dus dat is het probleem in ieder geval niet.

[ Voor 7% gewijzigd door Salandur op 10-11-2005 16:37 ]

[Salandur]

txIsolationLevelSerializable does the trick, alleen weet ik niet precies waarom (ik moet nog een geavanceerde J2EE cursus krijgen van mn werk)

[ Voor 28% gewijzigd door Salandur op 10-11-2005 17:06 ]

[Stephan Oudmaijer]

Salandur schreef op donderdag 10 november 2005 @ 17:06:
txIsolationLevelSerializable does the trick, alleen weet ik niet precies waarom (ik moet nog een geavanceerde J2EE cursus krijgen van mn werk)

Wel merkwaardig dat dit voorkomt ja... het is meer een Database level iets waardoor het fout gaat...

Zie: Connection.TRANSACTION_SERIALIZABLE

A constant indicating that dirty reads, non-repeatable reads and phantom reads are prevented. This level includes the prohibitions in TRANSACTION_REPEATABLE_READ and further prohibits the situation where one transaction reads all rows that satisfy a WHERE condition, a second transaction inserts a row that satisfies that WHERE condition, and the first transaction rereads for the same condition, retrieving the additional "phantom" row in the second read.

Maaruh, geavanceerde cursus? Dit is behoorlijk geavanceerd al

[Salandur]

CK schreef op donderdag 10 november 2005 @ 17:33:
[...]

...
Maaruh, geavanceerde cursus? Dit is behoorlijk geavanceerd al

offtopic:
ik heb alleen de basiscursus van Sun (FJ-310) gehad, maar heb me wel al een keer enigzins ingelezen in het concept van EJB's. jsp en servlet al van mijn opleiding.
Alleen nog niet echt de kennis in huis hoe bijvoorbeeld transactions precies werken en beveiliging van EJB/WAR/EAR precies werkt en wat wel en niet nodig is e.d. gelukkig over een maandje op cursus daarvoor