Expand +



A Pool for Everybody?

by Thomas G. Schuessler | SAPinsider

January 1, 2003

by Thomas G. Schuessler, ARAsoft SAPinsider - 2003 (Volume 4), January (Issue 1)
“advice carries more weight if it seems to
arise from lengthy contemplation.”
Colin Bruce, Conned Again, Watson!
Cautionary Tales of Logic, Math, and Probability

The SAP Java Connector (JCo1) allows you to connect to SAP2 using either a direct connection or a connection pool. When should you use which approach? Since most customers employ JCo to build browser-based multi-user applications, I will limit this discussion to those scenarios.

Pooled Connections for Generic Functions

JCo needs a Repository object for the metadata of the RFC-enabled Function Modules (RFMs) that your application calls. You should have exactly one Repository object per SAP system you communicate with.3 It is highly recommended that you use a connection pool of sufficient size for this Repository object so that JCo never has to wait for access to SAP’s metadata. Unused4 connections in a pool will be closed after an application-definable wait period so that the application does not hold on to precious SAP resources any longer than necessary.

A connection pool should also be used for generic functions required by all applications, like accessing metadata, retrieving help values, converting codes, etc. Of course, it is best to componentize all these generic functions so as to take advantage of caching read-only information in order to minimize the number of round-trips to the SAP system.

You could use the same connection pool for the Repository object and the other generic components. Most customers utilize a special generic userid with limited SAP authorizations for this pool.

Are You Authorized?

For access to security-critical SAP functionality (especially updates) you should always use “real” userids. And since a connection pool by definition uses the same userid for all its connections, the best option would seem to be to use direct connections for these userids. Recently, though, a customer for whom I taught an advanced JCo workshop surprised me with a different approach. In this company, they use a connection pool for every user. And once they explained the reason behind this, I became an instant fan. A direct connection to SAP is held from the moment the application issues the connect() call until it calls disconnect(). What if you have many users who start working with your application and then go to lunch or have to do some other work? Obviously, you do not want to keep their connections to SAP open for too long. One way of dealing with this issue is to set the HTTP session time-out to a comparatively low value and disconnect from SAP when the time-out occurs. The disadvantage here is that the user may be unhappy if the time-out happens too quickly and all user data bound to the HttpSession object (like a shopping basket) disappears.

Using a connection pool for each userid allows you to be more flexible. You can use a larger HTTP session time-out and a smaller value for the ConnectionTimeout5 property of the connection pool. In order to save memory in the JVM, you can remove the connection pool for the user when the HTTP session time-out occurs (and you are sure that this user does not have any other sessions using the same connection pool!).

Your naming convention for the connection pool names should make sure that the SAP system name, client number, and userid are all contained in the connection pool name in order to avoid unpleasant surprises if you run different applications in the same JVM.

External Commit Handling

Connection pools operate most efficiently when you release a connection back to the pool after each series of RFM calls that are executed without any user intervention. But you have to take into account that the SAP session is reset when the connection goes back to the pool. This is equivalent to typing /n in the Command Field (OkCode) of SAPGUI. In other words, all asynchronous update task records written since the last commit or rollback will be lost.

This is not a problem as long as you perform only read-only activities or call BAPIs that execute their own COMMIT WORK. Since most update BAPIs written for R/3 Release 4.0 and later require a separate commit, though, you have to make sure that the COMMIT WORK has been issued before you release the connection.

So, dive right in and have fun!

1The current version of JCo is 2.0.5. If you haven’t upgraded already, download a copy from

2For some time now, SAP has been marketing application components written in Java in addition to those written in ABAP. Also, SAP offers a full-blown J2EE Server as part of its Web Application Server product. Whenever I refer to “SAP” or “SAP system” in this article, I mean SAP application components written in ABAP (like R/3, BW, etc.).

3If you want to take advantage of extended metadata provided by a subclass of JCo’s Repository class (send me an email if you want to know more about this topic), you would use one Repository object per language and SAP system since the texts provided by the subclass are language-dependent.

4“Unused” in this context means that no application thread has acquired the connection via a call to getClient(). Once the connection has been acquired it will be kept alive even if the application does not ever use it again. Hence it is very important to return a connection to the pool if you no longer need it.

5The default is 600,000 ms (10 minutes).

Thomas G. Schuessler is the founder of ARAsoft (, a company offering products, consulting, custom development, and training to a worldwide base of customers. The company specializes in integration between SAP and non-SAP components and applications. ARAsoft offers various products for BAPI-enabled programs on the Windows and Java platforms. These products facilitate the development of desktop and Internet applications that communicate with R/3. Thomas is the author of SAP’s BIT525 “Developing BAPI-enabled Web Applications with Visual Basic” and BIT526 “Developing BAPI-enabled Web Applications with Java” classes, which he teaches in Germany and in English-speaking countries. Thomas is a regularly featured speaker at SAP TechEd and SAPPHIRE conferences. Prior to founding ARAsoft in 1993, he worked with SAP AG and SAP America for seven years. Thomas can be contacted at or at

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!