Description of problem: Without any real actions following log can be found in the log: 13:26:41,319 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss BPM Suite 6.0.2.GA (AS 7.2.1.Final-redhat-10) started in 103025ms - Started 540 of 614 services (71 services are passive or on-demand) 13:26:42,919 WARN [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes 13:26:45,913 WARN [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes 13:26:48,912 WARN [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes 13:26:51,913 WARN [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes 13:26:54,912 WARN [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes 13:26:57,912 WARN [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes 13:27:00,913 WARN [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes 13:27:03,913 WARN [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes 13:27:06,913 WARN [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes 13:27:09,913 WARN [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes The BPM is configured to use supported database Oracle 11 and the !!same!! configuration did not produced any logs like this in BPM 6.0.1 Though this error might not be dangerous it is very annoying as these log messages are very very frequent (tens / hundreds of them) Version-Release number of selected component (if applicable): BPM 6.0.2 + Oracle 11 How reproducible: always Steps to Reproduce: 1. Configure Oracle datasource in JBoss EAP 6.1.1 2. Configure business-central.war to use this datasource (persistance.xml) Actual results: messages like this are produced with no apparent reason 13:27:09,913 WARN [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes Expected results: no unnecessary WARN messages are produced Additional info:
workaround (standalone.xml): <logger category="org.hibernate.loader"> <level name="ERROR"/> </logger>
I can confirm this issue in BPMS 6.0.2.GA.
This comes form jbpm executor that queries for available jobs with locks. While it tries to get only first available job it will use the first and max result setting on pa query and by that can be seen as doing paging. And because of that it runs into this issue on hibernate side: https://hibernate.atlassian.net/browse/HHH-1168 the reason why it does locking is to minimalize race conditions between executor threads or executor instances in the cluster. Otherwise they might be fetching same job on different threads/server instance of a cluster. While it does not cause any issues it might cause some race conditions on Oracle due to this follow up locking which happens in second query. Since that is oracle specific we cannot change it to anything that will work same way for all data bases. I see two options: 1. we stick with what we have now and change logger level for deployments on oracle 2. we change implementation to not lock the result of the query that fetches job to execute and let the executor threads/server instances fail randomly on optimistic lock exception due to multiple threads trying to get the same job for processing. Personally I am in favor of using option 1 as it brings much better execution semantic on other data base and affects slightly oracle based deployments. While second one will affect all data bases. Moreover second will have higher rate of occurrences when more threads of executor are in use. For default it won't make bigger difference as there is single executor thread running.
I believe that we shouldn't introduce changes in our code base that might have negative effects. +1 for documenting the logging workaround.
*** Bug 1178849 has been marked as a duplicate of this bug. ***
This is a common issue with hibernate: http://stackoverflow.com/questions/22712195/hibernate-warning-about-follow-on-locking-using-oracle-10g The hibernate team has opened a jira to address this issue: https://hibernate.atlassian.net/browse/HHH-9097
Jiri or Anton, given comment 11, would it be okay to close this, since it's an issue with Hibernate and not the BPM suite?
Marco, I think it would be more suitable to re-assign this to the Doc Team. I would like to see the root cause and the configuration workaround in the Installing or Administration guide. What do you think? Or you would like to open a new BZ for that? Anton.
Anton, good idea: please do! Thanks.
Vikram, I have re-assigned this BZ to you as it requires doc update - either installing or admin guide. Users needs to be aware that when Oracle DB is used, the verbose logging(as showed in initial description) is expected behavior (as explained in comment 8) with possible workaround as explained in comment 2. Cheers, Anton
Thanks Anton. Changing component to Documentation.
Thanks Anton, Added a note in the Installation Guide for BPM Suite in the chapter: Setting up Persistence for Business Central. For the 6.1 Guides. This can be reviewed here [1]. Not setting this to ON_QA but directly to CLOSED-->NEXTRELEASE. [1] https://documentation-devel.engineering.redhat.com/site/documentation/en-US/Red_Hat_JBoss_BPM_Suite/6.1/html-single/Installation_Guide/index.html#Setting_up_Persistence_for_Business_Central