Probing WebLogic JDBC multipool issues

Problem Description There are two different types of WebLogic Server Multipool: High availability multipool and load balancing multipool. The two algorithms are incompatible and are used to achieve different goals. This mode provides information about both algorithms. Understanding the different types of WebLogic Server Multipool and the corresponding restrictions can help avoid common failures and find answers to common problems. This mode provides you with information about some common problems. This model also outlines the enhancements that are implemented for Multipool in the WebLogic Server version 8.1 sp3/7.0 SP5 and later versions. For more detailed information, we also provide links to relevant readings in our documentation. Troubleshooting provides background information about the WebLogic Server Multipool that helps you to sniff out problems and failures about Multipool: WebLogic server Multipool algorithm Multipool Restrict WebLogic Server version 8.1 sp3/7.0 SP5 and later enhancements for Multipool Quick Links: Learn about the common failures, frequently asked questions, and their solutions for WebLogic server Multipool reading materials

Understanding WebLogic Server Multipool This section provides background information about WebLogic Server Multipool and its algorithms, Multipool data source definitions, restrictions, and enhancements specifically for Multipool. WebLogic Server Multipool algorithm The WebLogic Server Multipool consists of an ordered set of JDBC connection pools that can be configured for high availability or load balancing. Please refer to the following documentation for an overview of these two situations: http://e-docs.bea.com/wls/docs81/jdbc/programming.html#1023962 (中文版). Many enhancements have been implemented in the WebLogic Server 8.1 sp3/7.0 SP5 and later, enabling a significant increase in the intelligence level of the MULTIPOOL algorithm-see enhancements for comparisons. However, the implementation of Multipool logic is very concise for WLS 8.1 sp3/7.0 SP5 Previous versions, as described in this article. Back to the top of the page High Availability Algorithms Multipool configured for high availability will always first try the first JDBC pool in its list. When Multipool is required to provide a connection, it will always try them in the order defined for each pool (that is, in the order of each pool in the JDBC Connection pool list). If the underlying database of the first JDBC connection pool fails, Multipool will still get the pool connection from the first JDBC connection pool. It tests the connection by issuing an SQL statement defined in the property testtablename defined in the JDBC connection pool. The test will fail because the database is not available. Multipool will then attempt to refresh the connection by creating a new physical connection to the underlying database. The attempt will still fail because the database is still faulty. At this point, Multipool will try the next JDBC connection pool in its ordered list. All of the above actions will be performed on each specific connection request. The next time you call Getconnection () for the same multipool, the same steps will be repeated. The logic is that, once the database of the JDBC connection pool (part of Multipool) is restored to normal, the connection should be refreshed for the next connection request, and the database will be reused immediately. Multipool will never mark the pool itself as a failure unless the administrator disables the pool. This allows administrators to influence the Multipool Failover mechanism by disabling the JDBC connection pool in the event of a underlying database failure, thereby avoiding the time cost of connection testing and recreating the connection in the first pool. You can use the WebLogic either through the console (http://e-docs.bea.com/wls/docs81/ConsoleHelp/jdbc_connection_pools.html#1115153 (Chinese)) or by using the. The Admin suspend_pool Command (Chinese) pauses the pool usage. http://e-docs.bea.com/wls/docs81/admin_ref/cli.html#1296729 (中文版). Once the database is back to normal, the same can be done through the console (http://e-docs.bea.com/wls/docs81/ConsoleHelp/jdbc_connection_pools.html#1115166 (中文版)) or perform weblogic. Admin resume_pool Command (中文版) to restore the use of the pool. http://e-docs.bea.com/wls/docs81/admin_ref/cli.html#1300251 Many enhancements are implemented for high availability algorithms-check for enhancements. Back to the top of the page Load Balancing algorithm The multipool of the load Balancing algorithm provides its connections in Round Robin mode, and the connections are evenly distributed between all the JDBC connection pools defined for it. If a connection test fails for a connection, Multipool attempts to provide a connection from the next pool in the list. The following location provides more details: http://e-docs.bea.com/wls/docs81/jdbc/programming.html#1023962 (中文版). Therefore, load balancing has the advantage of distributing the load between several pools and providing a certain degree of Failover capability when one of the pools is not available. However, if you adopt a load-balancing algorithm, you will not be able to control the order in which the Multipool responds to connection requests from different pools in its list and its Failover target pool. Restrictions on Multipool   To enable the High availability algorithm for Multipool, you need to consider some limitations and prerequisites. Details are provided in http://e-docs.bea.com/wls/docs81/jdbc/programming.html#1068130 (中文版). Here's a summary of the above points: Enable Testconnectionsonreserve on Jdbcconnectionpool (part of Multipool) so multipool can detect connection failures and Failover to the next in the list The need for JDBC connection pooling. The name of the Multipool must be unique within the domain configuration. JDBC connection pooling and Multipool should not be named with the same name, as that can cause Failover failures. if all the connections in the first pool are in use, Multipool will not provide a connection from the next pool in the list. Failover is provided only if the database in the JDBC connection pool in the Multipool configuration fails or when a pool is paused for use. However, a new property Failoverrequestifbusy was added to the WebLogic Server 8.1 SP3 and later, which can be configured with Multipool to implement when all connections in a pool are in use Provides a connection from the next pool in the list. This is described in more detail in the enhancements for Multipool in the WebLogic Server version 8.1 SP3 and later versions. When an application obtains a connection from Multipool, the connection is no longer executed for Failover during the application's use of the connection. This is because Multipool detects a connection failure while calling getconnection () during the connection test. The database failures that occur at the later stage need to be processed by the application, the same steps as for the normal JDBC connection pool. The transaction is rolled back as the database crashes or shuts down, so the application needs to handle the situation and rerun the related work. Multipool is not supported in distributed transactions, see: http://e-docs.bea.com/wls/docs81/jdbc/intro.html#1029935 (中文版) and http://e-docs.bea.com /wls/docs81/consolehelp/jdbc_multipools.html#1105912 (中文版). The use of Oracle RAC/TAF Multipool is not supported in distributed transactions because Oracle cannot guarantee that a transaction is initiated and terminated on the same RAC node when the driver is configured for load balancing. Please refer to the following location for more information: http://e-docs.bea.com/wls/docs81/jdbc/oracle_rac.html#1053178 (中文版). Set <connectioncreationretryfrequencyseconds= "0" > in all JDBC connection pools belonging to Multipool. Because Multipool configured for high availability normally Failover to the next pool in the list after a connection request to the database fails, setting the connection creation retry interval reduces efficiency and makes Multipool Failover. Please refer to the additional information provided in the following location: http://e-docs.bea.com/wls/docs81/jdbc/programming.html#1068305 (中文版). If a connection creation retry interval is set on one of the JDBC connection pools for Multipool, the following error message is displayed:

Java.sql.SQLException:Pool Connect Failed:weblogic.common.ResourceException:testMultiPool (mymultipool): Weblogic.common.resourcepool.ResourceLimitException:No currently available in pool Mymultipool to allocate to Applications, please increase the size of the pool and retry. At Weblogic.jdbc.common.internal.JDBCUtil.wrapAndThrowResourceException (jdbcutil.java:160)

Back to top  weblogic Server version 8.1 sp3/7.0 SP5 and later enhancements for Multipool The Multipool high-availability algorithm was improved in p> 8.1 sp3/7.0 SP5 and later, providing the following additional features: This pool is automatically disabled when a connection test and connection rebuild fails for a JDBC connection pool in the Multipool list. If the connection test on reserve is enabled and Testtablename is defined for the JDBC connection pool, you can enable this feature without any additional changes to the configuration. The database for the disabled pool is automatically tested when it resumes normal, and the JDBC connection pool is enabled again. To enable this feature, set the property healthcheckfrequencyseconds. Failover to the next pool in the list when all the connections in a pool are in use. To enable this feature, set the property failoverrequestifbusy to True. The makes it possible to control the Failover of another pool by registering a callback handler and to implement initialization and configuration tasks before performing Failover. To enable this feature, callback handlers need to implement the Weblogic.jdbc.extensions.ConnectionPoolFailoverCallback interface. You need to use attribute Connectionpoolfailovercallbackhandler to specify the implementation class. Makes it possible to control the activation of disabled pools by registering callback handlers and to implement initialization and configuration tasks before enabling. This feature will be executed by the callback handler mentioned in the above Failover control. The following location for describes the new functionality in detail: http://e-docs.bea.com/wls/docs81/jdbc/programming.html#1023962 (中文版). The following are the related properties to set on the Multipool (list):

<jdbcmultipool algorithmtype= "high-availability" name= "Demomultipool" poollist= "DemoPool2,demoPool" healthcheckfrequencyseconds= "240" Connectionpoolfailovercallbackhandler= "Com.bea.samples.wls.jdbc. Multipoolfailovercallbackapplication "targets=" Examplesserver/> Return to the top of the page

common faults, frequently asked questions and their solutions This section contains some common questions and answers about Multipool. WebLogic Server Multipool and Oracle Rac/taf which one is better for me. The level of Failover capabilities that Multipool and Oracle Rac/taf can provide is different. Depending on the configuration of Oracle Rac/taf, you can Failover a subset of the objects used in one database to the Failover node. For more information, consult the documentation for RAC/TAF on the Oracle site and the Oracle RAC (real application clusters) configuration and test mode. Rac/taf is an additional feature provided by Oracle and requires additional billing. BEA's Multipool (for high-availability configuration) is part of the WebLogic Server distribution, and its costs are included. It provides the ability to establish a list of JDBC connection pools and attempts to provide connectivity for connection pooling. If a database fails, it tries the next pool in the list. It cannot Failover any object in the failed database to the Failover instance. Using a scenario rather than using another scenario depends on the level of Failover transparency required and the amount of financial overhead you can afford. If the database fails when a connection is made from the pool, the Multipool feature is transparent to the application. After that, it's not transparent. If the connection is being used by an application, the application needs to handle rollback and Failover (and rerun work). how the High availability algorithm determines the connection in which connection pool in the Multipool list is used. Multipool will always try to provide a connection from the connection pool in the order of the JDBC connection pool defined for it. This means that for each connection request, Multipool will attempt to provide a connection from the first pool, and if it fails, the second pool will be tried, and if it still fails, a third pool will be attempted, and so on. Because the multipool itself never marks the pool as faulted or unavailable, Multipool still tries to provide the connection as described in the next connection request. This has been improved in the WebLogic Server version 8.1 sp3/7.0 SP5 and later, that is, if a connection request to one of the pools in the list fails, the pool is marked as faulted. For more information, see enhancements. What happens to the JDBC connection pool in the Multipool configuration if the database is shut down. When you get a connection from a pool, Multipool will test the database for failures by connecting to it. In other words, Multipool does not detect a failure of the JDBC connection pool database, but attempts to test and (if necessary) refresh the connection through a getconnection () call, and if it fails, the connection is provided from the next pool in the list. This has been improved in the WebLogic Server version 8.1 sp3/7.0 SP5 and later, that is, if a connection request to one of the pools in the list fails, the pool is temporarily disabled, and checks are performed at regular intervals to see if the database is back in use. For more information, see enhancements. How to disable the first (or any) JDBC connection pool so that Multipool can go directly to the next pool in the list. The JDBC connection pool can be temporarily disabled through the console, and the following location has a description of the operation: http://e-docs.bea.com/wls/docs81/ConsoleHelp/jdbc_connection_pools.html# 1115153 (中文版), or you can perform weblogic on the pool. The Admin suspend_pool command temporarily disables the JDBC connection pool, and the following location has a description of the operation: http://e-docs.bea.com/wls/docs81/admin_ref/cli.html#1296729 ( 中文版). For earlier versions of WebLogic Server, pass WebLogic. Admin temporarily disables the pool command is disable_pool. How to restore the use of the JDBC Connection pool (Multipool) after the underlying database resumes normal. You can re-enable the JDBC connection pool through the console in a similar way, and the following location has a description of the operation: http://e-docs.bea.com/wls/docs81/ConsoleHelp/jdbc_connection_pools.html# 1115166 (Chinese) can also be performed through WebLogic. The Admin resume_pool command re-enable the JDBC connection pool, and the following location has a description of the operation: http://e-docs.bea.com/wls/docs81/admin_ref/cli.html#1300251 (中文版 )。 In earlier versions of WLS 6.1 and 7.0, the name of the command was Enable_pool. How to enable JDBC connection pools that are disabled because of underlying database failures. Please refer to the answer to this question in the previous section. It takes such a long time to Failover the second pool by unplugging the network cable to test the Failover situation. WebLogic Server Multipool relies on testing and refreshing (rebuilding) The database connection to determine when Failover to the next pool in the list. This means that it relies on the underlying JDBC driver and network to test and create instant returns from the connection. However, pulling out a network cable in almost all cases results in a very long Failover, because the socket may take a period of time (up to a few minutes) before it really can return the error condition to the caller. A more effective and realistic Failover test method is simply to close the database or the corresponding listener or database computer itself. In the above case, the Failover time is much shorter. In this way, you can also check which type of driver (Class 2 or Class 4 driver) is returned faster from the connection test when the network cable is unplugged. Back to the top of the page

WebLogic Server documentation about Multipool FAQ   Questions: When Multipool should be used. Answer: http://e-docs.bea.com/wls/docs81/faq/jdbc.html#498177 (中文版) Question: Whether Multipool is supported in the cluster. Answer: http://e-docs.bea.com/wls/docs81/faq/jdbc.html#500584 (中文版). Related reading   How to configure WebLogic Server multipool:http://e-docs.bea.com/wls/docs81/consolehelp/jdbc_multipools.html# 1105912 (中文版). How to configure and deploy the JDBC components in WebLogic server and WebLogic server clusters: http://e-docs.bea.com/wls/docs81/ConsoleHelp/jdbc_ multipools.html#1105912 (中文版). Additional information about Oracle RAC is provided in Oracle RAC (real application clusters) configuration and test mode.

Known issues You can periodically view the WLS version of "Release Notes" in the Service Pack to understand the "Know n Issues "or" Resolved Issues "details and browse issues related to JDBC Multipool. For convenience, the following are links to these distribution notes: WLS 8.1 Release Notes (Chinese) WLS 7.0 Release Notes (中文版) WLS 6.1 Release Notes (中文版) for the need for special Please refer to the CR below and note in the release notes of the corresponding version of the Service Pack that there are already solutions for them: CR174575/CR175701-JDBC multipool Factor Group Subscript increment method is caused by unsafe load and fails, and throws Ind Exoutofboundsexception. To resolve this issue, changes have been made in WLS 8.1 SP3 (中文版). CR182879-When Multipool and ConnectionPool have the same name and Datasource/txdatasource are targeting this, the WebLogic Server does not throw an error during the startup process. To resolve this issue, changes have been made in the WLS 8.1 SP4.    Use the search feature to search for "release Notes", as well as other support solutions and CR-related information, such as more help is needed. The content mentioned in. If a customer signs a technical support contract, you can log in to http://support.bea.com/, and then log in to the browse Portlet provided for Solutions and Bug, where you can browse the latest available CR by product version.