专利名称：多池管理器的制作方法
技术领域：
背景技术：
诸如在California的San Jose的BEA系统中可用的WebLogicTM服务器之类的应用服务器允许用户进行很多功能。所述应用服务器典型支持的功能之一是提供数据库存取。在一个实施例中，由应用服务器提供诸如Java数据库连通性(JDBC)连接池(connection pool)之类的连接池。该连接池提供许多已设立的与数据库的连接。根据需要，将这些连接提供给应用服务器的应用。这样的连接池允许应用服务器中的相对多数量的应用来进行数据库存取，同时减少了应用的数据库连接时间。
发明内容
图1是图示了一个实施例的利用多池(multipool)管理器的多池的使用的图；图2A-2B是图示了使用具有有效连接池列表的多池管理器的图；图3A-3B是图示了一个实施例的有效连接池列表的使用的流程图；图4是图示了本发明一个实施例的多池管理器的操作的图；图5A-5B是图示了本发明一个实施例的利用多池管理器的回调(callback)的使用的流程图；图6是图示了本发明一个实施例的利用多池管理器的回调的使用的流程图。
具体实施例方式
使用自动维护的有效连接池列表的多池图1是图示了多池管理器102的操作的图。在一些系统中，期望具有多个数据库实例，诸如数据库实例104和106。例如，该数据库实例104和106中的每一个可包括在独立机器上运行的当前版本数据库。当存在多个数据库实例时，可期望使用多个连接池，诸如连接池108和连接池110。可以使用多池系统，而不是使诸如应用112、114、和116的每个应用专用(dedicating)于单个连接池并从而专用于单个数据库实例。在多池系统中，多池管理器102可确定使用哪一个连接池来获得应用到数据库系统的连接。
可能有不同的方法来选择连接池。一个选择方法具有主连接池和备份连接池。首先在主连接池上尝试连接，并然后当发生故障事件时，然后通过备份连接池发送所述连接。另一个方法是负载平衡方法，其中在多个连接池之间分配所述连接，以平衡不同连接池上的负载。循环复用(round robin)方法是负载平衡方法的示例。
本发明的一个实施例包括与数据库实例连接的、包括多个连接池202和204的多池系统。该连接池202和204适于提供到数据库实例206和208的连接。多池管理器210适于通过连接池选择和设立到数据库实例的连接。多池管理器210适于留意(keep track of)连接请求之间的无效(dead)连接池。
多池管理器210可以以避免任何无效连接池的方式来选择连接池。以图2A为例，如果连接池A无效，则多池管理器可避免选择该连接池A。在一个实施例中，根据应用所批准的，而仅进行未无效连接池的选择。在一个实施例中，应用通过回调或通过配置信息来指明是否切换连接池。
多池管理器210可适于维护有效连接池的列表212，并使用列表212来确定通过什么连接池来连接。术语“列表”不打算意指任何特定的数据结构。列表上的有效连接池可包括这样的连接池，即不是被多池管理器确定为无效的那些连接池。
可以在后台中测试无效连接池，以查看它们是否应该返回到有效连接池列表。该有效连接池列表可以是应用所提供的候选列表的子集。作为选择，可以维护分开的候选列表和有效列表，并且多池管理器可选择在该两种列表上的连接池。多池管理器210可以为与候选列表相关联的每个连接池存储指示(indication)，以指明连接池是有效还是无效。
在图2A的示例中，连接池A无效，因此没有在有效连接池列表212上。诸如应用220的应用可通过多池管理器210而请求连接到数据库实例206或208之一。在图2A中，多池管理器210选择通过连接池B的连接。
多池管理器210可在后台中异步地测试连接池是否已经再生效(revive)。在一个实施例中，可以使用异步后台测试模块214。
图2B图示了这个后台测试的示例。在这个示例中，SQL测试查询(query)被发送到无效连接池A。如果从数据库实例206获得正确回答，则多池管理器210可以用连接池A的指示来更新有效连接池列表212。以这个方式，当下次应用请求到数据库的连接时，通过连接池A的连接是可能的。
图3B图示了用于图示无效连接池的异步测试的流程图。在一个实施例中，在步骤300中，过去了预置等候时间。该等候时间可以由应用设置，并与多池管理器的配置信息一起存储，或者可以使用默认值。在步骤302中，测试无效连接池。如果如测试所指明的、无效连接池已经再生效，则更新有效连接池列表306，否则，所述循环重复步骤300中的等候预置时间。
图3A图示了在一个实施例中请求连接到数据库的操作。在步骤308中，在多池管理器处收到连接到数据库的请求。在步骤310中，多池管理器可选择连接池。在一个实施例中，多池管理器210选择有效连接池列表上的连接池。然后，可尝试所述连接。在步骤312中，检查连接池是否无效。如果连接池无效，则在步骤314中，更新有效连接池列表并从有效池列表中选择新的连接池。如果连接池没有无效，则在步骤315中进行检查以查看连接池是否充满(full)。如果没有可用的连接，则多池管理器可在步骤310中从有效连接池列表中选择另一个连接池。如果任一所选择的连接池都没有无效或者充满，则在步骤316中，通过所选择的连接池进行连接。
图4是图示了可以在本发明一个实施例中发生的不同条件的流程图。在步骤402中，多池管理器收到连接到数据库的请求。在步骤404中，多池管理器从有效池列表中选择连接池。如在步骤408中确定的，所选择的连接池有可能是重新再生效的连接池。如果是，则如在步骤410中所指明的，这是所谓的故障恢复(failback)。在步骤412中，检查连接池是否无效。如果连接池无效，则在步骤414中更新有效连接池列表，并在步骤416中从有效连接池列表中选择另一个连接池，这是所谓的故障转移(failover)条件。在步骤418中，如果连接池没有无效，则进行检查以查看连接池是否充满。如果连接池充满，则在步骤420中，进行检查以查看是否允许溢出(spillover)。如果允许溢出，则在步骤422中从有效连接池列表中选择另一个连接池。步骤424示出了进行连接。如下面所描述的，应用可利用回调或利用配置信息来批准故障恢复、故障转移、或溢出条件。
本发明的一个实施例是这样的多池管理器，其适于通过连接池而选择和设立到数据库实例的连接。该多池管理器适于留意无效连接池。该多池管理器实现了这样的选择方法，其中，多池管理器避免选择无效连接池，以便为应用提供连接。
本发明的一个实施例是包括多个连接池的、用于与数据库实例连接的多池系统。该连接池适于提供到数据库实例的连接。多池管理器适于通过连接池而选择和设立到数据库实例的连接。该多池管理器适于留意无效连接池，并异步测试连接池是否再生效。
多池的回调接口在一些实例中，期望在切换连接池之前与应用进行核对。切换连接池可以是复杂的处理。有时，存在优选的数据库实例，并且不期望用户切换到另一个更不可取的数据库实例，除非最初的数据库实例真的不可用。在本发明的一个实施例中，多池管理器实现对应用的回调，以便从应用得到批准来切换连接池。
在本发明的一个实施例中，多池系统用于利用多个连接池而连接到数据库实例。连接池502和504适于提供到数据库实例508和510的连接。多池管理器506适于通过连接池选择并设立到数据库实例的连接。多池管理器506适于在切换连接池之前与应用512进行核对。
在图5A的示例中，从多池管理器506到应用512的回调可用。如果要切换连接池，则多池管理器506可以进行到应用512的回调，以确定该应用是否将批准该切换。在图5A的示例中，有效连接池列表包括连接池B而不包括连接池A。在切换到连接池B之前，多池管理器506可进行到应用512的回调。在一个实施例中，在步骤1，多池管理器506收到连接请求。在步骤2，在多池管理器确定可能需要连接池切换之后，进行到应用512的回调。例如，该回调可以是对作为应用512的一部分的回调方法514的调用。该多池管理器506可存储配置信息506a，其可包括将在什么条件下发送回调的指示和/或回调方法名称的指示(在这个情况下，为回调方法A)。应用代码可以以任何方式实现回调方法514。在一个实施例中，多池管理器在步骤3中接收回调响应。该回调响应可以是多池管理器506可用于确定如何进行连接的指示。
在一个实施例中，回调响应指示包括“确认”指示。当收到“确认”指示时，多池管理器切换到新的连接池。另一个回调响应指示是“重试”指示。如果收到“重试”指示，则多池管理器506可尝试利用老连接池得到连接。另一个可能的回调响应指示是“不重新连接”指示。当收到“不重新连接”指示时，多池管理器不尝试进行连接。
图5B图示了回调方法可提供“重试”指示的可能原因。在一个示例中，可能期望在切换到辅助数据库实例之前进行一定数量的到主数据库实例的尝试。图5B图示了作为回调方法的一部分的、进行从应用512到数据库实例508的独立试通(ping)的示例。如果该独立试通提出数据库实例508仍旧在运行的指示，则应用可发送“重试”指示。如果应用512充分确信数据库实例停用，则可以发送“确认”回调响应。
应用512可以实现任何回调方法。在一个示例中，多池管理器具有可以用任何应用代码实现的回调接口。
图6是图示了一个实施例的回调操作的图。在步骤602中，检查是否如多池管理器所确定的那样将切换连接池。如果不切换连接池，则在步骤604中进行到连接池的连接。如果要切换连接，则在步骤606中，检查是否针对条件指明了回调。如果指明没有回调，则然后在没有回调的情况下通过新连接池进行连接。如果指明了回调，则在步骤610中，进行回调。如果收到“确认”指示，则在步骤614中利用新连接池进行连接。如果收到重试指示，则在步骤616中使用老连接池尝试进行连接。另外，如果收到“不重新连接”指示，则在步骤618中不通过连接池进行连接。
在一个实施例中，多池管理器适于通过连接池而选择并设立到数据库实例的连接。该多池管理器适于在切换连接池之前与应用进行核对。
一个非限制性示例的详细描述下面的描述将给出多池实现的一个非限制性实现。下面的描述给出一个实施例，但是本领域的技术人员将理解，可以进行上面构思的其它实现。下面给出的任何潜在限制语言是用于结合该特定非限制性实现的上下文进行解释的，而不是想要限制这些总构思。
多池可在故障转移之前与应用进行核对，以替换池。如果当前使用的池的配置测试遭遇随机的或短暂的故障、如果当将目前没有处理客户的数据库管理系统(DBMS)实例带回到服务中时应用希望进行控制、或者如果在得到来自池的连接时应用可以指定身份、并且应该返回来自匹配池的连接，则这是非常有用的。在DBMS出售者不提供在匿名JDBC连接上设置客户身份的固有(native)支持的情况下，这也是非常有用的。
可以对多池实现几处改善。
FAILOVER(故障转移)-现有的多池算法“HIGH AVAILABILITY”将被重新命名为“FAILOVER”。如果当前池忙，则将也可选地提供将连接的应用请求路由选择到替换池的能力。
HEALTH(健康度)-将改善现有的功能以标记无效的池，从而不将连接的应用请求路由选择到这些池。
CALLBACK(回调)-将向应用提供回调接口，以便在检测到出故障的池时，控制多池判决来故障转移到替换池，或者故障恢复到先前标记为无效的池。
应用可配置FAILOVER算法。FAILOVER可以通过主连接池来发送连接，并在主连接池发生故障时，通过辅助连接池来路由选择这些连接。如果当前的池繁忙，则FAILOVER还可可选地能够将针对连接的应用请求路由选择到替换池。
在一个实施例中，应用还将能够配置下面的多池属性/***如果设置，则在当前池繁忙时，将连接的应用请求路由选择到替换
*池。这仅仅在运行HIGH_ALGORITHM算法时相关。缺省意味着特*征被禁用。
**@param newVal新的属性值*@动态(dynamic)*@缺省错误(default false)*/public boolean isFailoverRequestIfBusy()；public void setFailoverRequestIfBusy(boolean failoverRequestIfBusy)；应用能够利用系统实现和注册回调。当多池检测到无效或繁忙的池时可调用该回调，这给予应用控制多池是否故障转移到替换池的能力。
在一个实施例中，应用将能够实现接下来的接口/*** 如果应用希望控制WebLogic服务器多池的故障转移行动，则该应用* 可以可选地实现这个接口。
** 如果应用已经注册了实现这个接口的、WebLogic服务器的类，* 则WebLogic服务器将调用这个接口的方法“allowPoolFailover()”，* 并取决于来自该方法的调用的返回代码来采取不同的行动。
* @见weblogic.management.configuration.JDBCMultiPoolMBean#setConnectionPoolFailoverCallbackHandler*/public interface ConnectionPoolFailoverCallback{//这个接口的名称，static public final String IF_NAME＝“weblogic.jdbc.extensions.ConnectionPoolFailoverCallback”；//方法‘allowPoolFailover()’的操作码static public final int OPCODE_CURR_POOL_DEAD＝0；static public final int OPCODE_CURR_POOL_BUSY＝1；static public final int OPCODE_REENABLE_CURR_POOL＝2；
// 方法‘allowPoolFailover()’的返回代码static public final int OK＝0；//对于即将发生的动作，应用为确认static public final int RETRY_CURRENT＝1；//重试当前池static public final int DONOT_FAILOVER＝2；//不进行故障转移，WLS将扔出weblogic.jdbc.extensions.PoolUnavailableSQLException/**多池将在各种故障转移/故障恢复条件下调用这个方法。应用应该基于*应用指定的语义来从这个方法返回上述定义的代码之一。
** @param currPool(当前池)-当前使用的连接池的名称，* 决不能为空** @param nextPool(下一池)-替换连接池的名称，* 对于操作码‘OPCODE_REENABLE_CURR_POOL’，将为空** @param opcode(操作码)-正执行的操作* OPCODE_CURR_POOL_DEAD-‘currPool’无效，多池需要将连接的* 应用请求故障转移到‘nextPool’。
** 应用应该返回“确认”、“RETRY_CURRENT”、或“DONOT_FAILOVER”，*这取决于希望多池做什么。
**OPCODE_CURR_POOL_BUSY-‘currPool’忙，多池需要将连接的应用请求重新路由选择到‘nextPool’**如果可以进行这个动作，则应用应该返回“确认”，*否则，应该返回其它返回代码中的任一个。
**OPCODE_REENABLE_CURR_POOL-‘currPool’先前被发现无效并因此被禁用。现在发现它已经健康，并且多池需要重新启用它。
**如果可以进行这个动作，则应用应该返回“确认”，*否则，应该返回其它返回代码中的任一个。
*/public int allowPoolFailover(String currPool，String nextPool，int opcode)；}应用可以将这个回调注册在JDBCMultiPoolMBean的属性“ConnectionPoolFailoverCallbackHandler”中。
/***用于设置实现接口weblogic.jdbc.extensions.ConnectionPoolFailoverCallback的应用类的绝对名称**@见weblogic.jdbc.extensions.ConnectionPoolFailoverCallback*@non-dynamic(非动态)*/public String getConnectionPoolFailoverCallbackHandler()；public void setConnectionPoolFailoverCallbackHandler(String className)；可以增强多池，以内部监视并跟踪下面的池的健康度。如果确定池无效，则将作出标记，并且不将随后的连接应用请求路由选择到该池。
在一个实施例中，应用将能够配置下面的JDBCMultiPoolMBean属性/***用于配置多池对先前被发现无效并因此被禁用的连接池的健康度进行*检查的频率。
**@param newVal新的属性值*@dynamic*@default 300
*/void setHealthCheckFrequencySeconds(int new Val)；int getHealthCheckFrequencySeconds()；可使用根据本公开的示教而编程的传统通用目的或专用数字计算机或(多个)微处理器来实现所述实施例，这对于在计算机技术领域的那些技术人员而言是显然的。有经验的程序员可基于本公开的示教容易地准备合适的软件代码，这对于在软件技术领域的那些技术人员而言是显然的。本发明还可通过准备集成电路或者通过互连传统组成电路的合适网络来实现，这对于本领域的技术人员而言是显然的。
一个实施例包括计算机程序产品，其是在其上(其中)存储有指令的(多个)存储介质，该指令可用于编程计算机以执行这里呈现的特征中的任一个。该存储介质可包括，但不限于任何类型的盘、ROM、RAM、EPROM、EPROM、DRAM、RAM、闪存装置、磁卡或光卡、Nan系统(包括分子记忆IC)、或者适合于存储指令和/或数据的任何类型的介质或装置，所述盘包括软盘、光盘、DVD、CD-ROM、微驱动器、和磁光盘。
在本发明中，在(多个)计算机可读介质的任一个上存储有用于控制通用目的/专用计算机或微处理器的硬件的软件、和用于使计算机或微处理器能够与人类用户或利用本发明的本发明结果的其它机械系统进行交互的软件二者。这样的软件可包括，但不限于装置驱动程序、操作系统、运行环境/容器、和用户应用程序。
已经为了说明和描述的目的而提供了本发明的优选实施例的前面描述。这不意欲穷举或将本发明限制到所公开的精确形式。对于相关技术领域的普通技术人员而言，许多修改和改变都是显而易见的。例如，可以以替换顺序来执行在所公开的本发明的实施例中执行的步骤，可省略某些步骤，并可增加其它步骤。为了最好地解释本发明的原理和它的实践应用，而选择并描述了所述实施例，从而使本领域的其它技术人员能够理解本发明具有适合于预期的特定使用的各种实施例和各种修改。意欲由权利要求及其等效来限定本发明的范围。
权利要求
1.一种用于连接到数据库实例的多池系统，包括多个连接池，所述连接池适于提供到数据库实例的连接；以及多池管理器，适于通过连接池而选择并设立到数据库实例的连接，所述多池管理器适于留意在连接请求之间的无效连接池。
2.根据权利要求1的多池系统，其中所述多池管理器测试连接池是否已经再生效。
3.根据权利要求2的多池系统，其中所示测试是在后台异步进行的。
4.根据权利要求2的多池系统，其中所述测试是以可以由应用设置的时间段、来周期性地进行的。
5.根据权利要求1的多池系统，其中所述多池管理器优先通过主连接池发送连接。
6.根据权利要求5的多池系统，其中辅助连接池存在溢出。
7.根据权利要求1的多池系统，其中所述多池管理器通过多个连接池来使得连接负载平衡。
8.根据权利要求1的多池系统，其中所述多池管理器在切换连接池之前与应用进行核对。
9.根据权利要求8的多池系统，其中所述多池管理器使用回调接口。
10.根据权利要求8的多池系统，其中所述应用利用多池系统注册回调信息。
11.根据权利要求1的多池系统，其中该多池管理器维护有效连接池列表，并使用该列表确定通过哪个连接池进行连接。
12.一种用于连接到数据库实例的多池系统，包括多个连接池，所述连接池适于提供到数据库实例的连接；以及多池管理器，适于通过连接池而选择和设立到数据库实例的连接，所述多池管理器适于留意无效连接池，并异步地测试连接池是否再生效。
13.根据权利要求12的多池系统，其中所述多池管理器优先通过主连接池发送连接。
14.一种用于连接到数据库实例的多池系统，包括多个连接池，所述连接池适于提供到数据库实例的连接；以及多池管理器，适于通过连接池而选择和设立到数据库实例的连接，所述多池管理器适于在切换连接池之前与应用进行核对。
15.根据权利要求14的多池系统，其中所述多池管理器具有回调接口。
16.根据权利要求14的多池系统，其中如果从应用收到“确认”指示，则所述多池管理器切换连接池。
17.根据权利要求14的多池系统，其中如果从应用收到“重试”指示，则所述多池管理器不切换连接池，并重试原始连接池。
18.根据权利要求14的多池系统，其中如果从应用收到“不重新连接”指示，则所述多池管理器不切换连接池，并且不重试原始连接池。
19.根据权利要求14的多池系统，其中所述多池管理器在进行故障转移之前与应用进行核对。
20.根据权利要求14的多池系统，其中所述多池管理器在进行故障恢复之前与应用进行核对。
全文摘要
多池(210)可留意无效连接池(202A)并可避免选择无效连接池(202A)。该多池(210)可在后台(214)检查连接池(202、204、…)是否已经再生效。
文档编号G06F15/173GK101095109SQ200580045638
公开日2007年12月26日 申请日期2005年12月21日 优先权日2004年12月31日
发明者拉胡尔·斯里瓦斯塔瓦 申请人:Bea系统公司