Bug 1234592
Summary: | Race condition with multiple job executor threads on Oracle | |||
---|---|---|---|---|
Product: | [Retired] JBoss BPMS Platform 6 | Reporter: | Martin Weiler <mweiler> | |
Component: | jBPM Core | Assignee: | Alessandro Lazarotti <alazarot> | |
Status: | CLOSED EOL | QA Contact: | Radovan Synek <rsynek> | |
Severity: | urgent | Docs Contact: | ||
Priority: | urgent | |||
Version: | 6.1.0 | CC: | ajuricic, alazarot, kverlaen, lywang, mczernek, omolinab | |
Target Milestone: | ER1 | |||
Target Release: | 6.2.0 | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | Bug Fix | ||
Doc Text: |
When using AsyncWorkItemHandler with Oracle Weblogic, a job can be picked up by two threads if the thread pool is larger than one. For queries which use rownum + for update, Hibernate breaks the query in two. This allows for the same job being processed by different AvailableJobsExecutor threads. To work around the issue, use custom dialect Oracle10gDialect that disables follow on locking and allows you to configure initial delay of executor work threads so they are not firing at exact same time.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1234806 1240665 (view as bug list) | Environment: | ||
Last Closed: | 2020-03-27 20:07:28 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1234806, 1240665 |
Description
Martin Weiler
2015-06-22 18:40:03 UTC
solution to is to provide configurable initial delay of executor work threads so they are not firing at exact same time, custom Oracle10gDialect that disables follow on locking used by hibernate by default. implemented on master with following commits jbpm master: https://github.com/droolsjbpm/jbpm/commit/5de80525e91db774b988718b05046cba64e40120 https://github.com/droolsjbpm/jbpm/commit/7bbe6d993f7e6d30bf1c95a71cf38a7cefd4b960 Maciej, I have just tested these changes on one-off patch (bug 1240665) and they seem to fix the issue. However, I am curious how we are going to propagate this in the future. Will all our customers be advised to use this new hibernate dialect? Should we do all our Oracle testing with this dialect? Because it will quite complicate testing process since we rely on default dialects. Is the new hibernate dialect the only way how to resolve this issue? Tomas, I would say for these users how have high volume requirement on executor and Oracle they should use this dialect. Ideally it would be best for hibernate team to include this dialect in there to allow use of it as one of the default dialects. When you look at default settings where only single thread is running it will not cause issues. Increasing number of threads to a reasonable size like number of cores should still work well. So my opinion is it should not be used as default one and only if the default is not capable of handling the load. Verified on BPMS 6.2.0 ER5 https://github.com/droolsjbpm/jbpm/pull/328 This should be documented since the fix means that customers should use org.jbpm.persistence.jpa.hibernate.DisabledFollowOnLockOracle10gDialect instead of org.hibernate.dialect.Oracle10gDialect if they want to avoid these problems with job executor on Oracle databases. |