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: |