What is JoltPooling?
PeopleSoft uses a middleware, Oracle Tuxedo to manage transactions between the application server and the database. PeopleSoft also uses Oracle Jolt for communication between PeopleSoft application server and the web server. When you install Tuxedo, Jolt gets installed by default and both, Tuxedo and Jolt are the required elements of the PeopleSoft application server.
The PeopleSoft servlets on the web server transmit requests and data through a connection to Jolt, which runs on the application server. Jolt extends Tuxedo capabilities by acting as the communication layer between the Java-based environment of the servlets and the C++ environment of the application server. You configure the servlets to direct requests from the web server to a predefined Jolt port on the application server.
Web browsers and integrated systems don’t send requests directly to the application server. Instead, they send HTTP/S requests to the PeopleSoft servlets running on the web server. The web server translates the HTTP/S request into a Jolt request that is sent to a specified Jolt port. Then the application server, running on Tuxedo, submits the appropriate SQL to the database.
What is JoltPooling?
So, just to recap what I mentioned earlier:
- The web server makes a connection to an application server using Jolt.
- Jolt manages and allows requests to Oracle TUXEDO services via a Jolt Service Listener or JSL, running on the TUXEDO server (application server).
- The Jolt API is embedded within the web server and is accessible from a servlet.
- A servlet basically connects to the Tuxedo using a session pool manager, which assigns a session based on availability and several other factors.
- This session is, then, connected to the Tuxedo system (application server) using Jolt.
JoltPooling is a configurable parameter, used to configure a Jolt session (connection) pool between TUXEDO and the web server.
JoltPooling refers to the “Jolt session pooling” directive which enables web server connections to be shared between user sessions. When Jolt Session Pooling is enabled, the session is shared across all the servlets (like psc, psp …etc). The existing sessions are shared across multiple servlets within Weblogic server which is expected to reduce the usage of system resources by sharing the user connection by pooled sessions such as threads and file descriptors…etc.
How to Configure JoltPooling
JoltPooling was introduced the first time starting from PeopleTools 8.46 and is enabled by default from PTools 8.48 onwards. It wasn’t an option in prior PTools releases.
There have been some known issues with enabled JoltPooling but they’ve subsided with newer PTools releases. If you’re using older PeopleTools release, you may consider disabling JoltPooling to see if it resolved the issue. However, with the newer and current release of PeopleTools, it is not something, which is recommended.
You control session pooling by modifying the joltpooling parameter.
To enable Jolt session pooling, set
joltPooling=true
To disable Jolt session pooling, set:
joltPooling=false
For PTools 8.46 to 8.49 the “joltpooling” exists in the web.xml file (under DOMAIN/PORTAL/WEB-INF directory).
For PTools 8.50 onwards, the parameter is in the configuration.properties file per site(under DOMAIN/PORTAL/WEB-INF/psftdocs/sitename directory).
If you decide to make changes to JoltPooling parameter, you’ll need to restart your webserver.
Note:
With “JoltPooling” enabled, the user name in App Server client status is replaced by JPOOL_XXXX, so if you had any scripts to take count of appserver clients, they may not work as desired.
With JoltPooling disabled, I captured the below screenshot for appserver client status. As you can see the highlighted user PS, which I was logged in:
With JoltPooling enabled, I captured the below screenshot for appserver client status. As you can see the user PS can no longer be seen and all you see is JPOOL_XXX connections:
