Closed adamalexandru4 closed 6 months ago
I've also tried with spring boot example and used Postgres. Created a basic users
table with optimistic locking and it also have failed for the same configuration. I really think that acquiring a lock should be followed by commit otherwise you can't achieve distributed lock and correct distributed scheduler.
Do I understand you correctly that you have reproduced this for Postgres as well? If it is only Oracle, and sporadic, it might be something similar to what have been observed for MSSQL (#348)
Btw, not sure why your Task-class is annotated with @Transactional
?
Yes, on Postgres the error is still present. I don't blame Oracle for this, the only issue (I can think of) may be the transaction autoCommit property ?
I'm using @Transactional
because I want all task code to run under same transaction and enhance it with Spring Transaction manager, not manual handling.
I really think that acquiring a lock should be followed by commit otherwise you can't achieve distributed lock and correct distributed scheduler.
Acquiring a lock is really setting picked=true. There is always a commit after that, before the ExecutionHandler
is called. I am not sure what is happening in your case. Could it be some other part of your code that is causing the deadlock? Parallell processing locking the same records?
I understand, but are you sure that this is how it works when you use spring transaction manager? I didn't configure anything about autoCommit but it is enabled by default, right?
As long as there is a Spring-managed transaction, autocommit-settings should not matter. I have not used Spring-managed transactions that much myself, but I have tested them and verified it works (with the boot-starter)
I think you need to debug the matter more in depth. For example, enable full SQL-logging and find the relevant missing statements.
(also not sure if there are nuances when setting Transactional
on the class-level)
After some digging in I've found that the issue comes from JdbcRunner
because the commitIfNecessary
won't commit because the Connection is a HikariProxyConnection wrapping a PgConnection (in my case) which has autoCommit
set to true
.
Sorry, I don't see the issue. You might try and create an integration-test in for example db-scheduler-boot-starter
that reproduces the issue.
Did you try to start more instances/replicas ? Testing in a single instance environment worked as expected, but when you scale up things goes wrong.
Did you ever get to the bottom of this?
Expected Behavior
Cluster should not reach a pessimistic lock exception in Oracle DB. I have one microservice deployed in K8S with 3 replicas. Do I have mess up transactional in any way or should I configure more things ?
Current Behavior
Exception
ORA-00060: deadlock detected while waiting for resource
.Steps to Reproduce the bug
Configuration app.properties
db-scheduler.enabled=true db-scheduler.heartbeat-interval=30s db-scheduler.polling-interval=10s db-scheduler.table-name=scheduled_tasks db-scheduler.immediate-execution-enabled=false db-scheduler.delay-startup-until-context-ready=true db-scheduler.threads=10 db-scheduler.polling-strategy=fetch db-scheduler.polling-strategy-lower-limit-fraction-of-threads=0.5 db-scheduler.polling-strategy-upper-limit-fraction-of-threads=3.0 db-scheduler.shutdown-max-wait=45s
Running the following task
Schedule task
Task
Context
Logs
c.g.kagkarlsson.scheduler.Scheduler : Unhandled exception during execution of task with name 'delete-project'. Treating as failure. .......... Caused by: java.sql.SQLException: ORA-00060: deadlock detected while waiting for resource