[jboss-jira] [JBoss JIRA] (WFLY-10182) Unstable work of the persistent EJB timers with Oracle DB. ORA-08177: can't serialize access for this transaction

[ https://issues.jboss.org/browse/WFLY-10182?page=com.atlassian.jira.plugin... ] Maxim Karavaev updated WFLY-10182: ---------------------------------- Description: The main signal is an exception in logs: {noformat} ORA-08177: can't serialize access for this transaction {noformat} When one cluster node is halted (the one on the witch "Timer" is actually working) then the other nodes are still can't catch up this "timer" from the DB due to the mentioned exception. Even worth scenario - when all nodes work perfectly, but occasionally all nodes start to decline, that timer is in the state IN_TIMEOUT and it really is due to the DB state, just because the last timer's invocation did not manage to commit final state after processing due to the same reason (SQL exception). So, why Oracle DB is so special? That's because it never manages transactions by themselves. It's full responsibility of the client. Looking into the code of the class {noformat} org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence {noformat} I didn't find transaction management, except one method, and even in it, I found, that it probably doesn't manage transaction as desired, due to the lack of resource participation. After I've made some changes to enable transactions for that functionality I have managed to stable EJB Timer logic on the server. Let's have a look at the attached patch (it's for 11 version, but it also works for 12). was: The main signal is an exception in logs: {noformat} ORA-08177: can't serialize access for this transaction {noformat} When one cluster node is halted (the one on the witch "Timer" is actually working) then the other nodes are still can't catch up this "timer" from the DB due to the mentioned exception. Even worth scenario - when all nodes work perfectly, but occasionally all nodes start to decline, that timer is in the state IN_TIMEOUT and it really is due to the DB state, just because the last timer's invocation did not manage to commit final state after processing due to the same reason (SQL exception). So, why Oracle DB is so special? That's because it never manages transactions by themselves. It's full responsibility of the client. Looking into the code of the class {noformat} org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence {noformat} I didn't find transaction management, except one method, and even in it, I found, that it probably doesn't manage transaction as desired, due to the lack of resource participation. After I've made some changes to enable transactions for that functionality I have managed to stable EJB Timer logic on the server. Let's have a look in attached patch. -- This message was sent by Atlassian JIRA (v7.5.0#75005)