Web Server JDBJ Connection Pool Issues

20th March 2015

by

In today’s article, I will be covering a common issue seen with JDBj connection pooling within the JD Edwards EnterpriseOne web client and its most common causes.

First, let’s talk high-level details on JDBj connection pooling. This is the internal component that creates, maintains, and cleans up the JDBj connections to the backend database for EnterpriseOne. By using fewer connections, the web server will use fewer local resources, and fewer database server resources, so it is important that this component be tuned properly to use what is needed for supporting end-users. If the web server runs out of connections, users will be unable to connect to the database and you will see errors like the example below in the logs. Under this scenario, connected users might still be able to operate normally but no new users/requests will function.

Error Message from JAS logs:

09 Mar 2015 08:29:57,400 [SEVERE] – [BASE] com.jdedwards.database.impl.physical.JDBMaxPoolSizeException: [DATABASE_CONNECT_FAILED] Database Connection failed for DataSource Object Librarian – 910.

There are many potential causes for the web server failing to establish a database connection but the key to this error message is the keyword “JDBMaxPoolSizeException”. In summary, what this error is telling us is: “I am trying to obtain a new connection to the database but there are no more available connections in the JDBC pool so I can’t connect and can’t proceed”.

Common Causes:

    1. JDBj connection pool configuration issues:
        1. You are using one proxy user for all your E1 users and you have more active users than connections available in the JDBj pool. To check the JDBj connection parameter within Server Manager, go to your web instance, and under the Runtime Metrics, click on “Database Connections”.

          This will show you information on your open connections:

          Solution: Increase the Maximum Connections parameter to be at least as high as Max Users. To do this, follow the steps below:In Server Manager, first find out how many users can connect to the web instance by viewing the “Web Runtime” section.

          The Max Users setting is the maximum number of users allowed to log in.

          To find the JDBj connection pool maximum, click on “JDBj Database Configuration”.

          Scroll down to the JDBj Connection Pools section and check the Maximum Connections. This should be equal to the Max Users setting from above.
        2. You are using one proxy user for each E1 user and you are opening too many connections per user because Pool Growth Size is not set to 1.
          Solution: Change the Pool Growth Size to 1** Do not make this change unless you are using one proxy user per E1 user. In other words, each E1 user has their own system user.
    2. You have too many connections because the database connections are not timing out, most likely because someone changed the connection timeout setting.
      Solution: Keep the Connection Timeout set to no more than 20 minutes (1200000)
    3. Tools Release bug

      1. With Tools Release 9.1.0.x there is also a JDBC connection pool leak that is fixed at TR 9.1.2. More on this issue can be found in this Oracle Solution 1488975.1 E1: JAS: JAS/Web Server Runs Out of JDBC Connections to the Database in Tools Release 9.1.0.x, which can be found at: https://support.oracle.com/epmos/faces/DocumentDisplay?id=1488975.1
    4. Case sensitivity on proxy user
      There is a configuration issue that can cause the Maximum Connections threshold to be reached much more quickly than normal. The JDBj connection pool is case sensitive, so if you have proxy users for your E1 users set with inconsistent capitalization, excessive connections can be opened since E1 considers the proxy user case/capitalization. Below is an example of what you will see for the JDBj Connection Pools in Server Manager when this condition happens. As you can see, user jdeproxy has two pool entries (one for each case) totaling 15 connections, instead of one entry.

      To fix this issue, you have to update all of the system users for each E1 user in the F98OWSEC to match by case and restart your JVM.Note: We have seen this case sensitivity issue in multiple customers in the last 10 years and we consider it a bug since it occurs regardless if the underlying database itself is case sensitive or not.The web server is an essential but complex piece of software, so tuning and maintenance of this and the underlying components are necessary to provide a stable and well performing experience for end-users. The connection pool is a key part of this process, so the suggestions above should help to achieve this.

Write a comment

Want to know more? Contact Us

FROM BLOG