performance CONNECTION POOLING BC4J

When Application was used by 80 users it work wery slow I think problem in CONNECTION POOLING
private Map m_pools;
public static final String[] APP_MODULE_NAMES = {
"StaffAppModule", "DossierAppModule", "ProcedureAppModule",
"ReportAppModule"
public static final String[] APP_MODULE_CONFIGURATION_NAMES = {
"StaffAppModuleLocal", "DossierAppModuleLocal",
"ProcedureAppModuleLocal", "ReportAppModuleLocal"
******* initialize pool START ********
m_pools = new HashMap();
PoolMgr mgr = PoolMgr.getInstance();
for (int i = 0; i < APP_MODULE_NAMES.length; i++) {
String poolName = APP_MODULE_NAMES[i] + "Pool";
ApplicationPool pool = mgr.findPool(poolName, PACKAGE,
APP_MODULE_CONFIGURATION_NAMES, null);
if (pool == null) {
pool = mgr.createPool(poolName, PACKAGE,
APP_MODULE_CONFIGURATION_NAMES[i], null);
m_pools.put(APP_MODULE_NAMES[i], pool);
******* initialize pool END ********
****** getAppModule START ***************
ApplicationPool pool = (ApplicationPool) m_pools.get(name);
log.debug("{ -- BusinessService ");
if (pool == null) {
return null;
SessionCookie sesCookie = pool.createSessionCookie(name,
IdFactory.createID(), null);
ApplicationModuleImpl appModule;
synchronized (this) {
log.debug("} -- synchronized ");
appModule = (ApplicationModuleImpl) sesCookie.useApplicationModule();
System.out.println("^^^ -- "+appModule.getClass());
appModule.setProperty(APP_MODULE_PROPERTY_SESSION_COOKIE, sesCookie);
return appModule;
****** getAppModule START ***************
<<< Can you help me performance CONNECTION POOLING ??? >>>

A Exception is thrown.

Similar Messages

Oracle.DataAccess 2.112.1.0 - Connection Pool Problem

Hi,
Oracle.DataAccess 2.112.1.0 is having connection pool problem. The no. of TCP connections to Oracle database keep increasing untill the server's session run out of limit. My application created connections, use them, close them, and dispose them properly. When using previous Oracle.DataAccess 2.111.6.20, the no. of TCP connections do not increase.
My database connection string has "Min Pool Size = 3 and Max Pool Size = 150".
With 2.111.6.20 version, TCP connection stays at 3.
With 2.112.1.0, TCP connection keep increasing for every 5 minutes. I've tried to disable Self Tuning, but still can't prevent the connections from increasing.
Later today, I downloaded Oracle.DataAccess 2.112.1.2 (it comes with ODAC 11.2.0.1.2) and test again, the problem is resolved... no more connection increases... but.... it is only for 32 bit Windows.
Unfortunately, there is no Oracle.DataAccess 2.112.1.2 for 64 bit Windows Server 2008.
May I know how can i resolve this problem on 64bit Window installed with Oracle 11g R2 client, which comes with Oracle.DataAccess 2.112.1.0, which has serious problems...(according to this 11.2 ODP.NET causing test runner failures )
Many thanks for your time and answers!
Edited by: user1502907 on 04-Sep-2010 23:01

Hi,
The only thing that jumps out within your problem description is that connections are being increased every 5 minutes. Are you sure its every 5 minutes and not 3 minutes which is the timing interval used by the Connection Pool facility to perform connection pool maintenance. If this occurs even when the application is idle then you could be running into the following known issue filed against 11.2.0.1.0 and fixed in 11.2.0.1.2.
Bug 9711600 - CONNECTIONS INCREASE BEYOND MAX POOL SIZE EVERY 3 MINUTE
This is specific to using the option CommandBehavior.CloseConnection when calling execute reader. Are you using this option and then also closing the connection in code before the datareader object is closed, if so you may be hitting this bug. You can also generate an ODP trace at level 15 of the behavior and if you see negative pool counts, that is also a diagnostic that points to this bug.
This is fixed in 11.2.0.1.0 Patch 3 or later for x64. If you have support, I recommend you open a service request to verify if this is your issue and if a patch set may help you.
Regards
Jenny B.

KIMYONG : Applications Database Connection Pool 관련 parameter 설명

Purpose
JVM 이 과도한 CPU / Memory를 사용하게 되어 Application Performance에 영향을 미칠때가 있으며 이럴경우 Connection Pool 관련하여 Parameter Tunning을 해야 할때가 있습니다. 이때 사용되는 Parameter들의 의미를 설명하고자 합니다.
The Applications Database Connection Pool is a pool of JDBC database connections that are shared among java applications. Applications obtain connections from the pool by using the getJDBCConnection(...) methods of AppsContext.
Essentially, each AppsContext has a single database connection associated with it at all times.
The AOL/J layer internally borrows and returns this connection to the pool as needed to maintain connection reference that is properly initialized for the current Java tier AOL security context and NLS state.
FND_MAX_JDBC_CONNECTIONS
============================
The maximum pool size is the maximum allowed sum of the number of available connections and thenumber of locked connections. If the pool reaches the maximum size and all connections are locked, new clients will not be able to borrow a connection until one of the current clients has returned one. The default setting for this parameter is essentially unlimited (about 2 billion).
FND_JDBC_BUFFER_MIN
======================
The buffer minimum is the minimum number of connections that the pool should try to maintain in the available list. When the buffer size falls below the buffer minimum, the pool maintenance thread will be notified to create new connections. When notified, the thread will immediately attempt to create the number of connections to fill the difference. New connections will not be created if the pool is already at its maximum size. When creating new connections the thread uses the attributes of the most recent client request that resulted in a new connection being created.
Setting this parameter to "0" will disable maintenance of the buffer minimum.
However, the buffer maximum will still be maintained.
Setting this parameter to a number greater than the maximum pool size(FND_MAX_JDBC_CONNECTIONS) will disable all buffer maintenance.
FND_JDBC_BUFFER_MAX
======================
The buffer maximum is the maximum number of connections that the pool should try to maintain in the available list. During heavy usage, the buffer may exceed this maximum. However, during periods of low usage, the maintenance thread will decrease the buffer size until the buffer maximum is reached.
If the value of this parameter is an integer, (for example "20") the buffer maximum is static. If the value is a percent (for example, "20%"), the buffer maximum is not constant but instead is calculated dynamically as a percent of total pool size. The buffer minimum is also taken into account when
determining a dynamic buffer maximum.
The exact expression used is:
maximum(t) = buffer minimum + ( (FND_JDBC_BUFFER_MAX/100) * size(t) )
where maximum(t) and size(t) are the buffer maximum and pool size at some time t.
The thread is configured to periodically check the buffer size. If the buffer size is greater than the maximum, the thread will remove either the number of available connections specified by FND_JDBC_BUFFER_DECAY_SIZE or the number of connections in excess of the buffer minimum, whichever is smaller. When connections are removed from the available list, the least recently used ones are removed first.
Setting this parameter to100%, or to a number equal to FND_MAXIMUM_JDBC_CONNECTIONS, or to a number less than or equal to FND_JDBC_BUFFER_MIN will effectively prevent the maintenance thread from ever removing any connections.
FND_JDBC_BUFFER_DECAY_INTERVAL
===================================
The buffer decay interval specifies how often the connection pool maintenance thread should check the buffer size. The thread will check the buffer size at most once every FND_JDBC_BUFFER_DECAY_INTERVAL seconds. The actual time between consecutive thread cycles will vary somewhat depending on the JVM load.
This parameter, along with FND_JDBC_BUFFER_DECAY_SIZE, allows the buffer decay rate to be tuned. For example, if the buffer decay size is 2 and the buffer decay interval is one minute, the buffer decay rate will never exceed two connections per minute. When connections are removed, the least recently used ones are removed first.
FND_JDBC_BUFFER_DECAY_SIZE
=============================
The buffer decay size specifies the maximum number of connections that should be removed during any single thread cycle during which the number of available connections is greater than the buffer size. This parameter, along with FND_JDBC_BUFFER_DECAY_INTERVAL, allows the buffer decay rate to be tuned.
FND_JDBC_MAX_WAIT_TIME
=========================
The maximum wait time specifies how much time a client should spend trying to get a connection. The borrow algorithm, used to borrow an object from the pool, contains check points at which the elapsed time is compared to the maximum wait time. If it exceeds the maximum wait time, then a null object will be returned to the client. The pre-configured value for the maximum wait time is
10 seconds.
FND_JDBC_SELECTION_POLICY
============================
The selection policy determines how a connection is selected from the list of available connections for a particular client. The connection pool is pre-configured to use a cost-based selection algorithm, which selects the connection that will require the smallest amount of initialization to match the
client's context.
FND_JDBC_USABLE_CHECK
===========================
The FND_JDBC_USABLE_CHECK parameter governs whether a pl/sql query is performed before giving a connection to a client. The pool checks whether a connection is usable before handing it to a client. This always involves checking that the connection is not null and is not closed. If FND_JDBC_USABLE_CHECK is set to true, then it also verifies that the connection can be used to perform a simple PL/SQL query. (This parameter may have to be set to "true" in order to clean up
connections to a database that has been restarted.)
FND_JDBC_CONTEXT_CHECK
==========================
The FND_JDBC_CONTEXT_CHECK parameter governs whether the AOL security context and NLS state is obtained from the database when the connection is returned to the pool. If FND_JDBC_CONTEXT_CHECK is "true", when the connection is returned to the pool, the AOL security context and NLS state will be obtained from the database. (This is implemented in the DBConnObj.isReusable() method). This check must be done when the connection is returned (rather than when it is borrowed) so that the selection matching algorithm has access to the actual
session context of the connections in the available list.
FND_JDBC_PLSQL_RESET
========================
The PL/SQL reset flag, set using the variable FND_JDBC_PLSQL_RESET, governs whether the PL/SQL state associated with a connection should be freed before the pool hands the connection to the client. By default this flag is false.
If the flag is set by true, by including the line "FND_JDBC_PLSQL_RESET=true" in the .dbc file, each connection to the database will have its PL/SQL state cleared before the pool returns the connection to the client.
This is how it works. After the pool selects a connection from the available list for a client, it initializes the connection. One of the things initialization does is to set a flag that is later used by SessionManager to determine if the apps initialization routine needs to be performed for the connection. When FND_JDBC_PLSQL_RESET has been set to "true", this flag will always be set to true. After the pool initializes the connection, it also checks whether the connection is usable. In this case, this check will include a call to DBMS_SESSION.RESET_PACKAGE, which frees the PL/SQL state. The table below summaries the affect of FND_JDBC_PLSQL_RESET and the other safety check parameters on borrowing a connection from the pool.
The FND_JDBC_PLSQL_RESET parameter has been added to only to address the case where production PL/SQL global bugs are known to exist. The performance of the pool is reduced by setting this flag to true.
Reference : Note 264599.1

Purpose
JVM 이 과도한 CPU / Memory를 사용하게 되어 Application Performance에 영향을 미칠때가 있으며 이럴경우 Connection Pool 관련하여 Parameter Tunning을 해야 할때가 있습니다. 이때 사용되는 Parameter들의 의미를 설명하고자 합니다.
The Applications Database Connection Pool is a pool of JDBC database connections that are shared among java applications. Applications obtain connections from the pool by using the getJDBCConnection(...) methods of AppsContext.
Essentially, each AppsContext has a single database connection associated with it at all times.
The AOL/J layer internally borrows and returns this connection to the pool as needed to maintain connection reference that is properly initialized for the current Java tier AOL security context and NLS state.
FND_MAX_JDBC_CONNECTIONS
============================
The maximum pool size is the maximum allowed sum of the number of available connections and thenumber of locked connections. If the pool reaches the maximum size and all connections are locked, new clients will not be able to borrow a connection until one of the current clients has returned one. The default setting for this parameter is essentially unlimited (about 2 billion).
FND_JDBC_BUFFER_MIN
======================
The buffer minimum is the minimum number of connections that the pool should try to maintain in the available list. When the buffer size falls below the buffer minimum, the pool maintenance thread will be notified to create new connections. When notified, the thread will immediately attempt to create the number of connections to fill the difference. New connections will not be created if the pool is already at its maximum size. When creating new connections the thread uses the attributes of the most recent client request that resulted in a new connection being created.
Setting this parameter to "0" will disable maintenance of the buffer minimum.
However, the buffer maximum will still be maintained.
Setting this parameter to a number greater than the maximum pool size(FND_MAX_JDBC_CONNECTIONS) will disable all buffer maintenance.
FND_JDBC_BUFFER_MAX
======================
The buffer maximum is the maximum number of connections that the pool should try to maintain in the available list. During heavy usage, the buffer may exceed this maximum. However, during periods of low usage, the maintenance thread will decrease the buffer size until the buffer maximum is reached.
If the value of this parameter is an integer, (for example "20") the buffer maximum is static. If the value is a percent (for example, "20%"), the buffer maximum is not constant but instead is calculated dynamically as a percent of total pool size. The buffer minimum is also taken into account when
determining a dynamic buffer maximum.
The exact expression used is:
maximum(t) = buffer minimum + ( (FND_JDBC_BUFFER_MAX/100) * size(t) )
where maximum(t) and size(t) are the buffer maximum and pool size at some time t.
The thread is configured to periodically check the buffer size. If the buffer size is greater than the maximum, the thread will remove either the number of available connections specified by FND_JDBC_BUFFER_DECAY_SIZE or the number of connections in excess of the buffer minimum, whichever is smaller. When connections are removed from the available list, the least recently used ones are removed first.
Setting this parameter to100%, or to a number equal to FND_MAXIMUM_JDBC_CONNECTIONS, or to a number less than or equal to FND_JDBC_BUFFER_MIN will effectively prevent the maintenance thread from ever removing any connections.
FND_JDBC_BUFFER_DECAY_INTERVAL
===================================
The buffer decay interval specifies how often the connection pool maintenance thread should check the buffer size. The thread will check the buffer size at most once every FND_JDBC_BUFFER_DECAY_INTERVAL seconds. The actual time between consecutive thread cycles will vary somewhat depending on the JVM load.
This parameter, along with FND_JDBC_BUFFER_DECAY_SIZE, allows the buffer decay rate to be tuned. For example, if the buffer decay size is 2 and the buffer decay interval is one minute, the buffer decay rate will never exceed two connections per minute. When connections are removed, the least recently used ones are removed first.
FND_JDBC_BUFFER_DECAY_SIZE
=============================
The buffer decay size specifies the maximum number of connections that should be removed during any single thread cycle during which the number of available connections is greater than the buffer size. This parameter, along with FND_JDBC_BUFFER_DECAY_INTERVAL, allows the buffer decay rate to be tuned.
FND_JDBC_MAX_WAIT_TIME
=========================
The maximum wait time specifies how much time a client should spend trying to get a connection. The borrow algorithm, used to borrow an object from the pool, contains check points at which the elapsed time is compared to the maximum wait time. If it exceeds the maximum wait time, then a null object will be returned to the client. The pre-configured value for the maximum wait time is
10 seconds.
FND_JDBC_SELECTION_POLICY
============================
The selection policy determines how a connection is selected from the list of available connections for a particular client. The connection pool is pre-configured to use a cost-based selection algorithm, which selects the connection that will require the smallest amount of initialization to match the
client's context.
FND_JDBC_USABLE_CHECK
===========================
The FND_JDBC_USABLE_CHECK parameter governs whether a pl/sql query is performed before giving a connection to a client. The pool checks whether a connection is usable before handing it to a client. This always involves checking that the connection is not null and is not closed. If FND_JDBC_USABLE_CHECK is set to true, then it also verifies that the connection can be used to perform a simple PL/SQL query. (This parameter may have to be set to "true" in order to clean up
connections to a database that has been restarted.)
FND_JDBC_CONTEXT_CHECK
==========================
The FND_JDBC_CONTEXT_CHECK parameter governs whether the AOL security context and NLS state is obtained from the database when the connection is returned to the pool. If FND_JDBC_CONTEXT_CHECK is "true", when the connection is returned to the pool, the AOL security context and NLS state will be obtained from the database. (This is implemented in the DBConnObj.isReusable() method). This check must be done when the connection is returned (rather than when it is borrowed) so that the selection matching algorithm has access to the actual
session context of the connections in the available list.
FND_JDBC_PLSQL_RESET
========================
The PL/SQL reset flag, set using the variable FND_JDBC_PLSQL_RESET, governs whether the PL/SQL state associated with a connection should be freed before the pool hands the connection to the client. By default this flag is false.
If the flag is set by true, by including the line "FND_JDBC_PLSQL_RESET=true" in the .dbc file, each connection to the database will have its PL/SQL state cleared before the pool returns the connection to the client.
This is how it works. After the pool selects a connection from the available list for a client, it initializes the connection. One of the things initialization does is to set a flag that is later used by SessionManager to determine if the apps initialization routine needs to be performed for the connection. When FND_JDBC_PLSQL_RESET has been set to "true", this flag will always be set to true. After the pool initializes the connection, it also checks whether the connection is usable. In this case, this check will include a call to DBMS_SESSION.RESET_PACKAGE, which frees the PL/SQL state. The table below summaries the affect of FND_JDBC_PLSQL_RESET and the other safety check parameters on borrowing a connection from the pool.
The FND_JDBC_PLSQL_RESET parameter has been added to only to address the case where production PL/SQL global bugs are known to exist. The performance of the pool is reduced by setting this flag to true.
Reference : Note 264599.1

ABAP MDM Connection Pool concept? Slow Performance in call

Hi,
I'm playing around with the MDM ABAP API, and I found the performance a bit disappointing.
I followed the guide "How To identify master data records using SAP MDM 5.5 ABAP API's" and wrote a test program.
The program makes a connection, triggers an MDM query, and disconnects.
    CREATE OBJECT api
      EXPORTING
        iv_log_object_name = logical_object_name.
    api->mo_accessor->connect( language ).
* Query parameters
    ls_query-parameter_code = 'Material_Number'.
    ls_query-operator = 'CS'.
    ls_query-dimension_type = 1.
    ls_query-constraint_type = 8.
    ls_value = '70'.
    GET REFERENCE OF ls_value INTO ls_query-value_low.
    APPEND ls_query TO lt_query.
    CLEAR ls_query.
* Search
    CALL METHOD api->mo_core_service->query
      EXPORTING
        iv_object_type_code = 'Products'
        it_query            = lt_query
        iv_hits_max         = 10
      IMPORTING
        et_result_set       = lt_result_set.
Connection is really fast (a split second)
First time triggered 'query' method took about 30-50 seconds.
Second time triggering 'query' method took a split second.
Further to my investigation, I found out the most expensive code lies in
CL_MDM_PROVIDER_SP04_PL03->IF_MDM_CORE_SERVICES~QUERY
*--- load field meta data ---*
IF mt_mdm_field_meta_data IS INITIAL
OR mt_field_meta_data     IS INITIAL.
    CALL METHOD me->_load_field_information.
ENDIF.
Within this method loadfield_information, it rips all the table and structure information
from MDM, and ALL language texts and so on.
It has many loops, and within the loops querying MDM for more information.
Is there anyway to speed this up?
Why aren't these data cached? (They don't change so often in a production environment)
I also found a shared memory class CL_MDM_METADATA_ACCESS but it is not used anywhere.
No shared memory area relevant is delivered by SAP as well.
Any ideas?
Cheers,
Michael.

Hi Michael,
you're welcome.
I'm not sure how the Connection Pooling to MDM is really done by the ABAP APIs as I'm unfortunately not an API developer but just use the API for my programms.
What I learned during this process is that the repository meta data (meaning table descriptions, and so on) have to be loaded at least once for each connection. This makes sense because a repository can always be changed manually by any user. And I don't think that it would be faster to hold the meta data persistent in the ABAP layer because then you would need to compare the ABAP available meta information with the current meta information of the repository. This could take even longer.
I've solved this "issue" in a way that I really rely on the connection because a single connection is very stable. So I call the "CONNECT" only once in the very beginning, run through my coding and the very last step is the "DISCONNECT". As long as a connection is available, the meta data is cached in the API layer (at least this is the case for SP05).
BR Michael

BC4J Connection Pooling

In the BC4J document About Connection Pooling it reads, If the connection pool manager cant create a connection it waits for one (up to the timeout value).
What happens if the timeout value is exceeded?

A Exception is thrown.

Oracle: slow performance with SELECT using ojdbc14 and connection pooling

Hello,
i'm working hard the last days to solve a performance problem with our customer using a oracle 10g database. For testing I used our oracle 9.2.0.1.0 database which shows the same symptoms. All doing solved nothing: the performance while using this oracle is much slower than other databases. This result I cannot trust and so I need some advice. What is missing to improve the performance on the java side?
The webapplication I use runs fast on MySQL 4.x and SQLServer 2000, but on the above mentioned Oracle it was always 4 times slower. The webapplication uses a lot of simple SELECT-Statements without complicated joins and so on (because it should run on many different databases). Doing some days of creating tests within this webapplication, I was not able to find any entrance point for a change. All databases server I'm using, having only the default configurations after a common installation.
To reduce the complexity I wrote a simple java application with connection pooling using only the latest libraries from apache-commons(dbcp, pool), and the latest ojdbc14 for oracle 9.2.
First the results than the code: MySQL needed less than 1000 millisecond, SQLServer around 1000 milliseconds and Oracle over 2000 milliseconds. I stopped pooling and the results are for Oracle even worse: over 18000 milliseconds (mysql:2500, sqlserver:4100).
I changed the classes for Oracle and used the class oracle.jdbc.pool.OracleConnectionCacheImpl from the ojdbc14-library. No difference (around 100 milliseconds more or less).
The only Select-Statement works on this table, which has one index on HICTGID.
It contains 259 entrances.:
CREATE TABLE HIERARCHYCATEGORY (
HICTGID NUMBER (19) NOT NULL,
HICTGLEVEL NUMBER (10) NOT NULL,
HICTGEXTID NUMBER (19) NOT NULL,
HICTGEXTPARENTID NUMBER (19) NOT NULL,
HICTGNAME VARCHAR2(255) NOT NULL
);The application simply loops through this table using
SELECT Hictgid, Hictgname FROM HIERARCHYCATEGORY WHERE HICTGID = ?, but I always open a connection before this query and closes this connection afterwards. So I use the pooling as much as possible. That's all SQL I'm using.
 protected static DataSource setupDataSource(String sDriver, String sUrl, String sUser, String sPwd) throws SQLException {
 BasicDataSource ds = new BasicDataSource();
 ds.setDriverClassName(sDriver);
 ds.setUsername(sUser);
 ds.setPassword(sPwd);
 ds.setUrl(sUrl);
 // The maximum number of active connections:
 ds.setMaxActive(3);
 // The maximum number of active connections that can remain idle in the pool,
 // without extra ones being released, or zero for no limit:
 ds.setMaxIdle(3);
 // The maximum number of milliseconds that the pool will wait (when there are no available connections)
 // for a connection to be returned before throwing an exception, or -1 to wait indefinitely:
 ds.setMaxWait(3000);
 return ds;
 }I can switch by using external properties between three databases (oracle, mysql and sqlserver) and if I want I can switch pooling off. And all actions I'm interested are logged by Log4J.
 public static Connection getConnection() throws SQLException {
 Connection result = null;
 String sJdbcDriver = m_oJbProp.getString("jdbcDriver");
 String sJdbcUrl = m_oJbProp.getString("databaseConnection");
 String sJdbcUser = m_oJbProp.getString("dbUsername");
 String sJdbcPwd = m_oJbProp.getString("dbPassword");
 try {
 if (m_oJbProp.getString("useConnectionPooling").equals("true")) {
 if (log.isDebugEnabled()) {
 log.debug("ConnectionPooling true");
 if(null == m_ds) {
 m_ds = setupDataSource(sJdbcDriver,sJdbcUrl,sJdbcUser,sJdbcPwd);
 if (log.isDebugEnabled()) {
 log.debug("DataSource created");
 result = m_ds.getConnection();
 } else {
 // No connection pooling:
 if (log.isDebugEnabled()) {
 log.debug("ConnectionPooling false");
 try {
 Class.forName(sJdbcDriver);
 result = DriverManager.getConnection(sJdbcUrl, sJdbcUser, sJdbcPwd);
 } catch (ClassNotFoundException cnf) {
 log.error("Exception: Class Not Found. ", cnf);
 System.exit(0);
(.. ErrorHandling ...)Here is the code fragment which is doing the work:
 StringBuffer sb = new StringBuffer();
 while (lNextBottom <= lNextCeiling) {
 con = getConnection();
 innerSelStmt = con.prepareStatement("SELECT Hictgid, Hictgname FROM HIERARCHYCATEGORY WHERE HICTGID = ?");
 innerSelStmt.setLong(1, lNextBottom);
 rsInner = innerSelStmt.executeQuery();
 if ((rsInner != null) && (rsInner.next())) {
 sb.append(rsInner.getLong(1) + ", " + rsInner.getString(2) + "\r");
 if (log.isDebugEnabled()) {
 log.debug("Inner Statement: " + rsInner.getLong(1) + "\r");
 rsInner.close();
 con.close();
 lNextBottom++;
 if (log.isInfoEnabled()) {
 log.info("\rResult values: Hictgid, Hictgname \r");
 log.info(sb.toString());
 }and the main method:
 public static void main(String[] args) {
 try {
 long lStartTime = System.currentTimeMillis();
 JdbcBasic oJb = new JdbcBasic();
 boolean bSuccess = false;
 bSuccess = oJb.getHierarchycategories();
 if (log.isInfoEnabled()) {
 log.info("Running time: " + (System.currentTimeMillis() - lStartTime));
 if (null != m_ds) {
 printDataSourceStats(m_ds);
 shutdownDataSource(m_ds);
 if (log.isInfoEnabled()) {
 log.info("Datasource closed.");
 } catch (SQLException sqe) {
 log.error("SQLException within main-method", sqe);
 }My database values are
databaseConnection=jdbc:oracle:thin:@SERVERDB:1521:ora
jdbcDriver=oracle.jdbc.driver.OracleDriver
databaseConnection=jdbc:jtds:sqlserver://SERVERDB:1433/testdb
jdbcDriver=net.sourceforge.jtds.jdbc.Driver
databaseConnection=jdbc:mysql://localhost/testdb
jdbcDriver=com.mysql.jdbc.Driver
dbUsername=testusr
dbPassword=testpwdThanks for your reading and maybe for your help.

A few comments.
There is of course another difference between your test cases then just the database. There is also the driver. And I suspect that in at least the case with the jtds driver it is helping you along where you are doing something silly and the Oracle driver is not.
Before I explain the next part I would say the speed differences between MS-SQL and MySQL look about right I think you are aiming here for MS-SQL level performance not MySQL. (For a bunch of reasons MySQL is inherently faster but there are MANY drawbacks as well which have been well discussed on previous threads)
Here is where I believe your problem lies
while (lNextBottom <= lNextCeiling) {
 con = getConnection();
 innerSelStmt = con.prepareStatement("SELECT Hictgid, Hictgname FROM HIERARCHYCATEGORY WHERE HICTGID = ?");
 innerSelStmt.setLong(1, lNextBottom);
 rsInner = innerSelStmt.executeQuery();
 if ((rsInner != null) && (rsInner.next())) {
 sb.append(rsInner.getLong(1) + ", " + rsInner.getString(2) + "\r");
 if (log.isDebugEnabled()) {
 log.debug("Inner Statement: " + rsInner.getLong(1) + "\r");
 rsInner.close();
 con.close();
 lNextBottom++;
 }There at least four things that are wrong with above.
1) Why are you preparing the statement INSIDE the loop. Let us for a moment say that the loop will spin 100 times. That means that you are preparing the same statement 100 times. This is bad. It is also very relevant because for example the Jtds driver is going to be caching the prepared statements you make so that actually while you try and prepare it 100 times it only actually does it once... but in Oracle I don't know what it is doing for sure but if it is preparing on each pass well than that bit of it is going take 100 times longer then it should.
2) You are opening and closing the connection on each pass through the loop... also a terrible idea. You need to fix this first so that you can repeatedly use the same prepared statement.
3) Why are you looping in the first place? More on this later.
4) Where do you close the PreparedStatement? It doesn't look like you do.
Okay so for starters your loop should look a lot more like this...
code]
con = getConnection();
innerSelStmt = con.prepareStatement("SELECT Hictgid, Hictgname FROM HIERARCHYCATEGORY WHERE HICTGID = ?");
while (lNextBottom <= lNextCeiling) {
innerSelStmt.setLong(1, lNextBottom);
rsInner = innerSelStmt.executeQuery();
if ((rsInner != null) && (rsInner.next())) {
sb.append(rsInner.getLong(1) + ", " + rsInner.getString(2) + "\r");
rsInner.close();
lNextBottom++;
innerSelStmt.close();
con.close();
I think the code above (and you can put your debug stuff back if you want) which uses ONE connection and ONE prepared Statement will improve your performance dramatically.
The other question though I would as is why in the hell you are doing 100 or whatever number of queries anyway. This can be done all in ONE query which again will improve performance.
Your query and such should look like this I think.
String sql = "SELECT Hictgid, Hictgname FROM HIERARCHYCATEGORY WHERE HICTGID >=? AND HICTGID<=?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setLong(1,lNextBottom );
ps.setLong(2,lNextCeiling);
ResultSet rs = ps.executeQuery();
while(rs.next()){
// your appending to string buffer code goes here
}and I can't understand why you're not doing that in the first place.

Connection pool performance

Barry,
You should post this to Performance newsgroups (please dont cross post)
This actually depends on how many execute threads you have - if you have 101
clients / applications requesting connections concurrently, only the once
that can get a Execute Thread will actually be able to use a connection and
complete. Rest of the application requests will be queued up.
sree
"Barry Myles" <[email protected]> wrote in message
news:40b47cdd$1@mktnews1...
>
Hi there I wonder if anyone could shine some light on the subject ofconnection
pooling configuration for me
In the connection pool If I have
initial capacity = 50
Maximum Capacity = 100
and then get a period with 101 concurrent applications all wanting towrite information
to the backend database at the same time, what happens to that oneapplication?
is it forced to wait until a thread becomes available, does it just blockuntil
this happens or does it give up right away? (if it does what exception
is generated if any?)
Also I'm trying to pin down some performance issues with the use ofconnection
pooling, can someone guide me as to what a typically under performingconfiguration
for a connection pool would be.

Javamail performance and connection pooling

Dear Javamail users and programmers,
I am new to javamail. We are working on a commercial web mail project and using Javamail to connect with an IMAP/SMTP clustered server group to read and write mails.
Our application will have 400000 concurrent users in the system and an Approximate , we will have 200 servers (Glassfish 3 ) and each server will have 2000 active users at time.
Now my problem! At the moment, we are opening the store each time we read or store mails for each user. I doubt this will have performance issues in production.
Does anyone have experience using Javamail in this dimension?
I read the connection pooling mechanism in the package com.sun.mail.imap Descriptio. If i understood correctly, this will require at-least one dedicated connection per user to the server . I think, that will be too many connections at a time for any Imap server cluster system.
Is there any other method of doing connection pooling?
Btw in which scenario I should increase the mail.imap.connectionpoolsize to more than one? I assume, i only need to increase this parameter if i want to keep more than one folder open for a particular user at time, isn't it?
What will be the best approach which suite to our application?
Thank you very much for any help.
With regards,
Alvin Antony

Connection pooling isn't likely to help in your scenario. IMAP connection pooling does not allow multiple
users to use the same connection to the server. Unless you want to map all of your web mail users to a
single IMAP user, connection pooling won't help you.
The general issue of managing sessions and connections was discussed briefly in this other thread:
[http://forums.sun.com/thread.jspa?threadID=5423307|http://forums.sun.com/thread.jspa?threadID=5423307]
I suspect you're going to need to do some experiments to determine the best approach.

BC4J Question: How does AM and Connection Pooling work?

Hello everybody,
we are just trying to understand what exactly happens when a BC4J Application Module is created / when a AM is checked out of the pool with respect to Connection and Application Module Pooling. Especially we would like to understand what ConnectionStartegies, EnvInfoProvider and SessionCookies exactly do and when and how to customize them. Especially we would like to use features like virtual private databases (VPD) and proxy authentication (a feature of the Oracle OCI JDBC driver) with BC4J application modules. We found the HowTo about using JAAS and VPDs with BC4J (http://otn.oracle.com/products/jdev/howtos/bc4j/bc4jvpdjaas.html) but there are still questions, e.g. when is the afterConnect() method of an ApplicationModuleImpl called? During the instanciation of an AM or every time it's check out of the pool?
Any info on this topic would be very welcome!
Regards
Stefan

Hi,
1. Setting jbo.doconnectionpooling=false ,
connection pool still exists.
Is it correct ? When you set this parameter to false, you are saying that Connection Pool is not managed by AM, so you need to specify a JNDI Name in Application Module to use a Pool not managed by AM.
2. There is one situation to set
jbo.doconnectionpooling=true. The article said
"when you have a large number of application
module pools all needing to database connections
from the same underlying application user at the
database level. In this case, the many application
module pools can perhaps economize on the total
overall database sessions by sharing a single,
underlying database connection pool of JDBC
connections, albeit at a loss of efficiency of each
one. This choice would be favored only if total
overall database sessions is of maximum priority. "
Does it mean that if we set it to true when we
have many many AM instances and we cannot afford to
have such number of connection instance in the pool
? It's means that the JDBC connections will be shared avoid new Connection at time.
Normally i use Connection Pool not managed by Application Module.
Bye

Low Application Performance due to AM connection pooling configuration

Hi All,
My application performance is too slow due to default App module connection pooling parameters. I started exploring on these parameters in oracle documentation and was stopped due to some doubts.
The below link is actually the one from which I'm doing the configuration.
http://docs.oracle.com/cd/E21764_01/web.1111/b31974/bcampool.htm
1. I want to know what value should be in Weblogic server --> Maximum capacity (I think they confused me a little saying it can be equal to AM's Maximum Pool Size, Maximum Available Size, Minimum Available Size).
2. Then the AM's Initial pool size should be equal to the weblogic's Initial Capacity. I have 10 AM, if I'm setting 100 in each AM, then the corresponding weblogic's initial capacity should be equal to 100 or 100 X 10. Please clarify this.
Thanks.

You post give no information which connects the pooling parameter to 'low' performance. Have you checked where all the time is consumed? Which method or part of the application consumes the most time. Before you can't answer these questions you can't link the problem to am pooling.
Here are some pointers
http://andrejusb.blogspot.de/2011/10/experimenting-with-adf-bc-application.html
http://andrejusb.blogspot.de/2012/01/adf-performance-marathon-22-hours.html
and there are some more articles available on Andrejus's blog...
Timo

RFC_FAILURE affects Connection Pool

Using VB.NET (2003) with .Net Connector 2.0.
An intermittent problem causes a RFC Call to fail, and an exception is raised in the .NET code. The Exception message is:
 See RFC trace file or SAP system log for more details
The Trace file shows:
ERROR file opened at 20051115 131423 GMT Standard
 T, SAP-REL 640,0,78 RFC-VER 3 759904 MT-SL
T:2844 Could not send rfc container 0x130
T:2844 <* RfcCall [1] : returns 1:RFC_FAILURE
T:2844 <* RfcCallReceive [1] : returns 1:RFC_FAILURE
>TS> Tue Nov 15 13:14:24 2005
T:2844 <* RfcCleanupContext [1] : returns
 18:RFC_INVALID_HANDLE
T:2844 <* RfcCleanupContext [1] : returns
 18:RFC_INVALID_HANDLE
This error adversely affects the Connection Pool as calls to other RFCs are now prone to similar intermittent errors
Is there any way to prevent the problem causing problems with Connection Pool ?
Is there any way of removing a faulty connection from the pool ? (NB Close and Dispose on the connection does not help)

The application is a Windows service - so I don't want to lose any connections. I assume that closing the connection (and not returning it) will affect the number of available connections in the pool(?).
I'm using async. RFC call, and the problem is detected in the callback function when the EndRFCCall is performed.
Original code:
Public Sub Execute_RFC(ByVal parameters as string())
' Assign SAP Connection to RFC Proxy
sapRFCProxy.Connection = SAPConnectionPool.GetConnectionFromPool(ConnectString)
Call the SAP RFC - Asynchronously
arAsyncResult = m_sapRFCProxy.BeginRFCCall( params..., AddressOf RFC_CallBack, objAsyncState)
End Sub
Private Sub RFC_CallBack(ByVal ar As IAsyncResult)
Try
 ' Retrieve the SAP RFC Response...
 Call sapRFCProxy.EndRFCCall(ar, param1, param2, etc...)
Catch ex As Exception
 ' Log the Error...
End Try
' Return the Connection
Call SAPConnections.ReturnConnection(sapRFCProxy.Connection)
End Sub
I have changed the code as suggest so that the connection is closed, disposed but not returned. This cleared the RFC_INVALID_HANDLE errors, but the main problem of a corrupted connection persists.
Diagnostics produced by the amended code:
Trace File (Info):
2005-11-16 11:55:46Z Warning: RfcCleanupContext failed. Closing connection
dev_RFC.trc
ERROR file opened at 20051116 115546 GMT Standard T, SAP-REL 640,0,78 RFC-VER 3 759904 MT-SL
T:3068 ======> CPIC-CALL: 'CMSEND'
ERROR program state check for conversation 99610798
TIME Wed Nov 16 11:55:46 2005
RELEASE 640
COMPONENT CPIC (TCP/IP)
VERSION 3
RC 471
MODULE r3cpic.c
LINE 2576
DETAIL called function STSEND in state state=BUFFER_DATA2
COUNTER 1
T:3068 <* RfcCall [20] : returns 1:RFC_FAILURE
T:3068 <* RfcCallReceive [20] : returns 1:RFC_FAILURE
T:3068 <* RfcCleanupContext [20] : returns 1:RFC_FAILURE
Even with the change to the code, a call to a reliable RFC will now fail intermittently with:
T:2876 Could not send rfc container 0x130
T:2876 <* RfcCall [24] : returns 1:RFC_FAILURE
T:2876 <* RfcCallReceive [24] : returns 1:RFC_FAILURE
Thanks

Doubts concerning External Connection Pool

A few questions:
1. How can I set up an external connection pool with toplink? or in another words, assuming that I have successfully configured a connection pool (and a datasource) on my weblogic app-server, how do I configure Toplink to use the same?
2. I am trying to achieve the above (refer point 1), by defining my custom connector (by extending TOPLink.Public.Sessions.DefaultConnector). The custom connector provides connections using the dataSource.getConnection(). Now, the question is
- Where will the pooling happen in this case? i.e. Will Toplink use its own connection pool (populate its own connection pool with container managed data source), and issue connections (container managed) from there or will it make use of the container managed pooling (and ask for connections from the container managed pool, as and when required)? The subtle difference being, weblogic will not be able to validate a connection before issue in the former case.
3. This question is similar to point 2, but talks in terms of a practical example. Assuming that if I am using the custom connector successfully in my code, then if I pull out the network cord and reconnect again, I expect the container to provide me with a valid connection (as weblogic can be configured to perform a validity check on a connection before issuing). I am getting a 'connection reset by peer' error in my application (indicating that either the container fails to provide a valid connection, or toplink does not use the container managed pool effectively). I guess, Toplink still uses its own pool but this time it is pooling container managed dataSources. Since the connections are issued from Toplink and not container, here is no validation/reconnection happening for the connection, before issue. Please comment if I am thinking in the right direction or not. If not, how you can explain the above failure?
4. My aim is to utilise the container's connection pool, and Toplink's ability to perform the rest of the things (including transactions). Is that possible?

Vikas,
TopLink can easily be configured to use the external connection pool of an server. This can be accomplished with API but more commonly using the sessions.xml configuration file for the SessionManager. In the product we ship examples for WLS that make use of data sources configured in the server. The portion of the sessions.XML file in question is:
 <login>
 <user-name>weblogic</user-name>
 <password>weblogic</password>
 <datasource>java:comp/env/jdbc/ejbJTSDataSource</datasource>
 <non-jts-datasource>java:comp/env/jdbc/ejbNonJTSDataSource</non-jts-datasource>
 <uses-external-transaction-controller>true</uses-external-transaction-controller>
 <uses-external-connection-pool>true</uses-external-connection-pool>
 </login>
 <external-transaction-controller-class>oracle.toplink.jts.wls.WebLogicJTSExternalTransactionController</external-transaction-controller-class>
This sets TopLink up with both data source access to the JTA and non-JTA connection pools. The full example also includes a domain where the data source is configured.
When TopLink is using the connection pool of the server (external connection pooling) it will not pool its own connections. TopLink will request a connection from the pool each time one is required and release it back when done. This leaves the server responsible for the number of connections available and also for supporting database re-connection.
Doug

Connection pool SAPPool is exhausted

hi..
I am getting this following error in my application
om.sap.mw.jco.JCO$Exception: (106) JCO_ERROR_RESOURCE: Connection pool SAPPool is exhausted. The current pool size limit (max connections) is 50 connections.
at com.sap.mw.jco.JCO$Pool.getClient(JCO.java:5366)
at com.sap.mw.jco.JCO$PoolManager.getClient(JCO.java:6324)
at com.sap.mw.jco.JCO$PoolManager.getClient(JCO.java:6269)
at com.sap.mw.jco.JCO.getClient(JCO.java:8536)
at com.tcs.interfaces.sapConnectionUtility.JCOClient_Connection.connectToSAP(JCOClient_Connection.java:21)
at com.tcs.interfaces.wifi.outbound.DisablingWifi.disableWifi(DisablingWifi.java:110)
at com.tcs.interfaces.jco.StartJob.run(StartJob.java:68)
at java.lang.Thread.run(Thread.java:636)
The front end PMS (Property Management System) - SAP Customised product is unable to connect with the JCo Middleware server because of the above mentioned error.
The thing is that in java application I have set the maximum pool size (SAPPool) to 50.
Still we are facing this error twice a week.
Is there any kind of setting in SAP server side where JCo RFC connection limits can be set ?
Can any pls help in this regard.

After reading the url that you have pointed out: i have a question our from my
curiosity:
is there any overhead that does have if connection pool is very high say 100 and
the required is say like 70.
Thank You very much.
Rob Woollen <[email protected]> wrote:
I usually recommend that for production systems. There's some info here:
http://edocs.bea.com/wls/docs81/perform/WLSTuning.html#1123237
-- Rob
Mike wrote:
Thanks Rob,
is it a good idea to make InitialCapacity equal to the MaxCapacity?
say making InitialCapacity = MaxCapacity = 50
while thread count is also = 50
Rob Woollen <[email protected]> wrote:
Typically thread count = connection pool size is a good starting point.
You might want thread count > connection pool size if you want to
throttle work to the database, or if you have some threads which will
never require a db connection.
You might want connection pool size > thread count if remote clients
are
starting transactions or reserving connections. Another case is if
a
single thread starts multiple transactions.
-- Rob
Mike wrote:
what is the relationship between thread count and connection pool
Eg, if i have a thread count of =50
and connection pool = 36
how does these 2 parameters work together ?
is there any equation between the 2 ?
--Mike

Difference between using app server connection pooling and using the driver

Hi all,
How to get connection pooling with out application server and tomcat also?
What is the difference between using app server connection pooling and using the driver supported connection pooling?
Regards,
Murali

maybe the performance of App server pool is better than the JDBC pool,
for you don't know wether the implementation of the JDBC interface is good or bad.

Connection pool and Connection factory difference?

Hi,
Can someone clarify the difference between connection pool and connection factory.
I know connection pool is some thing like a pool of database connection manitained at one place so that an application or client can use it when it requires.
Then wat exactly is connection factory..say in 10g we always put a connection factory name in all adapters and acces the data sources like DB ,FTP,AQ ..etc
can someone clarify??
regards,

To conserve system resources and to improve the performance of transactional applications, WebLogic allows you to define a pool of client connections (generally database but may be a FTP,FILE etc. as well)
A Connection Factory object encapsulates a set of connection configuration parameters that has been defined by an administrator. A client uses it to create a connection with a service provider (generally JMS).
Regards,
Anuj

performance CONNECTION POOLING BC4J

Similar Messages

Maybe you are looking for