Database Connection Pooling
Is there a commonality between a plane and a database connection? – Yes, they are both very expensive resources. Most people – even frequent flyers – would not maintain their own plane, nor would they consider to buy one and resell it after a flight. Similar for database connections. Creating a fresh database connection (and destroying it after use) is very time consuming and creates a lot of overhead on the system. Keeping it open on the other hand, pins significant amounts of memory to ensure good database performance. This is also expensive and thus highly inefficient if the connection is only being used once in a while.
Like for planes, a viable solution is to share some ready-to-use database connections amongst different users. This is what is commonly called Database Connection Pooling. Applications making use of this service, “get” a database connection when they are in need of one and “return” it back to the pool afterwards. This is the more efficient, the cheaper the associated “get” and “return” operations are.
Like other Java servers, SAP NetWeaver Application Server Java (AS Java) relies on database connection pooling. During server startup for example, this can easily avoid > 10,000 connection open/close actions resulting in factor 5 to 10 better performance to the end user.
If you run a product that is based on AS Java, like SAP Enterprise Portal or SAP PI on IBM i, SAP notes 2682037 and 2696944 are of special interest to you.
General Performance Improvement
The first, SAP note 2682037 – “IBM i: Performance Improvement affecting Java Connection Pooling”, delivers a performance benefit regardless of your support package level. This note is taking advantage of a new JDBC feature to significantly reduce runtime for a health check that occurs any time a connection is being returned to the pool, which, as you have seen above, is a frequent action because of AS Java architecture.
A Performance Problem and its Solution
The second, SAP note 2696944 – “Slow performance due to missing or compromised connection pooling”, addresses a problem that was introduced with SAP note 2368649. Users affected by this would suddenly suffer from very bad overall response times. This is, because connection pooling stopped working, turning cheap get/return operations into expensive open/close connection operations on the database.
You should take action if you are running at or have just applied one of the following “J2EE ENGINE SERVERCORE” support package levels:
- 7.30 SP017 – SP019
- 7.31 SP020 – SP024
- 7.40 SP015 – SP019
- 7.50 SP007 – SP013
You should in this case also apply note 2696944 to avoid unwelcome performance impacts from SAP note 2368649. Mind that there aren’t patches for some of the older SP levels affected. In that case you might want to go to a newer SP level.
We recommend that everyone running AS Java on IBM i implement SAP Note 2682037 for a simple performance boost, and that you should not forget to implement SAP Note 2696944 when moving to or if you are already running any of the support package levels mentioned to avoid having any unwelcome performance impacts.