[Logo] Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
Messages posted by: gumis  XML
Profile for gumis -> Messages posted by gumis [6]
Author Message
Sorry I made a mistake. Of course we are using default isolation mode which is READ_COMMITED
I don't think it is deadlock - I mean it is not situation that the first transaction is waiting for resource acquired by the second and the second for the resource acquired by the first.
Transaction timeout is much longer then distributed_lock_timeout and the second transaction gets ORA-02049 waiting for lock acquired by first transaction.

I rather suspect something like described here:
"TX-4 is a complete different matter. I faced TX-4 problems twice. The first one was related to the lack of free ITL slots in a table (or index), I don't remember."
TX isolation level is SERIALIZABLE.
Scheduler.scheduleJob(jobDetail, trigger) from quartz 1.6.6
Thanks, but I would like to understand it a bit better.
How it is locked? I thought that when you set lockOnInsert = false quartz do not perform any additional locking to standard locking applied by database when you insert/update rows.

Scenario is following:
- There are one long transaction and in scope of this transaction job is scheduled
- There are many rather short transaction also inserting jobs
Problem: Long running transaction prevents from inserting jobs from short transaction.
Statement on which we got timeout is from OracleDelegate.insertJobDetail(OracleDelegate.java:190):
JOB_DATA) VALUES(?, ?, ?, ?, ?, ?, ?, ?, ?)

lockOnInsert property is set to false.

Do you have idea why oracle blocks this insert statement? I would not expect such behaviour event if there is another transaction running that already inserted another job.

Thanks for help,
Profile for gumis -> Messages posted by gumis [6]
Go to:   
Powered by JForum 2.1.7 © JForum Team