Uploaded image for project: 'JBoss BPMS Platform'
  1. JBoss BPMS Platform
  2. RHBPMS-3668

BPM produces verbose WARN messages when configured with Oracle 11

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 6.1.0
    • 6.0.2
    • Documentation
    • None

      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:

              rhn-support-vigoyal Vikram Goyal (Inactive)
              rhn-support-agiertli Anton Giertli
              Jiri Svitak Jiri Svitak (Inactive)
              Vikram Goyal Vikram Goyal (Inactive)
              Jiri Svitak Jiri Svitak (Inactive)
              Anton Giertli, brms-docs brms-docs (Inactive), David van Balen (Inactive), Jiri Svitak (Inactive), Kris Verlaenen, Maciej Swiderski (Inactive), Marco Rietveld (Inactive), Marek Baluch, ravindra.tubati
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: