CN102193820A - 用于向应用提供异构连接对象的连接处理器和方法 - Google Patents

Abstract

公开了用于向应用提供异构连接对象的连接处理器和方法。本发明涉及一种连接处理器(1)，用于向至少一个应用(2)提供多个异构连接对象(300、301)中的至少一个，其中所述连接处理器(1)包括：a.一个或多个异构内部连接池(30、31)，其中每个内部连接池(30、31)适合于提供除了其它内部连接池(30、31)的配置之外的特定配置的同构连接对象(300、301)；和b.接口(10)，适合于从所述至少一个应用(2)接收至少一个请求，其中所述至少一个请求包括特定配置的连接对象(300、301)的标识，并且其中所述接口(10)还适合于作为响应向所述至少一个应用(2)提供来自相应内部连接池(30、31)的连接对象(300、301)。

Description

用于向应用提供异构连接对象的连接处理器和方法

技术领域

本发明涉及一种用于向应用提供异构连接对象的连接处理器和方法。

背景技术

现代软件应用通常与各种外部数据存储(例如数据库)通信，以便取回要处理的数据并且存储所处理的数据。为此，应用必须建立到各个数据存储的连接，这涉及打开连接、取回和/或存储数据以及最后关闭连接。然而，每次当需要这种连接时由应用本身建立连接是非常耗时的并且消耗了应用和要连接的数据存储两者的大量处理能力，这导致性能的降低。

为此，已知提供包括到特定数据存储的一组预先配置的单个连接的连接池。通常，连接池提供的连接的属性是在配置连接池期间静态地预先定义的，并且不能在随后运行时改变配置。应用可以从连接池请求连接并且在它完成其处理之后将连接返回到池中。连接池可以保持返回的连接，以便其由另外的应用重用。因此，连接池隐藏了在创建和管理连接时涉及的复杂性。

然而，已知的连接池实现被设计为仅仅维持同构连接，即给定连接池内的所有连接具有相同配置/属性，所述配置/属性在池的配置期间定义。例如，在用于JDBC数据库的连接池中，所有连接将指向相同的数据库服务器、模式、用户名和密码。

在该情况下，US 7,222,179B2公开了资源池，其管理资源对象的创建，以及池收缩，即销毁不用的资源对象。然而，所公开的资源池遵照连接池的上述原理，所以资源池仅能够向客户提供同构资源。

此外，US 2006/0146877A1、US 2006/0146878A1和有关的因特网引用“JDBC MultiPools”(参照http://download.oracle.com/docs/cd/E13222_01/wls/docs81b/ConsoleHelp/jdbcmultipools.html)公开了维持多个连接池的多池管理器，每个连接池针对于给定数据库的具体实例(即克隆)。多池管理器所服务于的所有连接是同构的，即它们仅仅用作连接到相同的物理数据库，尽管多池管理器关注对同构连接池间请求的负载均衡。

上面的方法在复杂的应用场景中是特别不利的，其中例如基于运行时的值，即基于仅在应用运行时期间可确定的值，应用需要到不同数据存储的连接，即具有不同配置的连接(异构连接)。例如，在消息队列连接中，对具体用户来说，取回消息的队列名称可能不同，其不能在应用实际运行之前被确定。

为了克服上面的缺点，应用通常被编程为必要时才使用连接池，如果应用需要与连接池提供的连接配置不同的连接则自己创建另外的连接，从而实际上绕开了连接池。然而，该方法除了难于实现并且易于出错之外，具有另外的缺点：手动创建的连接不能得益于连接池提供的优点。这导致应用内的资源和处理时间使用方面的额外开销。

另一个已知的解决方法是在应用中手动缓存曾经建立的连接，以便在随后的时间点由应用重用它。然而，该方法是非常无效率和复杂的，因为应用基本上必须接管应该由连接池执行的所有任务，例如创建和销毁连接、移除无效的连接、处理超时和期满、处理异常和清理、以及在例如池更新这样的情况下通知其它相关的连接。

第三个已知方法是在预先知道随后需要的连接的配置的情况下，配置许多连接池。然而，由应用处理一个以上的不同连接池是非常耗时和耗费资源的，并且因此是不可接受的。

最后，应用可以使用一个连接池来取回所有的连接，其中应用根据需要改变所取回同构连接的配置，并且在连接返回到池中之前重置配置。明显地，这仅仅对于在连接创建之后可以被改变的非常简单的配置来说是可行的，并且不适用于复杂的应用场景。

因此，本发明潜在的技术问题是提供了一种向应用提供连接的改进方法，该方法是更有效并且不容易出错的，由此至少部分地克服了上述的现有技术的缺点。

发明内容

根据本发明的一个方面，该问题由用于向至少一个应用提供多个异构连接对象中的至少一个的连接处理器来解决。在权利要求1的实施例中，连接处理器包括：

a.一个或多个异构内部连接池，其中每个内部连接池适合于提供除了其它内部连接池的配置之外的特定配置的同构连接对象；和

b.适合于从至少一个应用接收至少一个请求的接口，其中至少一个请求包括特定配置的连接对象的标识，并且其中接口还适合于作为响应向至少一个应用提供来自相应内部连接池的连接对象。

因此，实施例定义了一种连接处理器，其封装和内部地管理内部连接池内的特定配置的连接对象，并且还适合于当被请求时向应用提供连接对象。连接对象通常涉及数据存储，例如数据库或者应用期望使用的任何其它组件，并且用作为到该数据存储的句柄。一旦向应用提供了连接对象，应用可以经由连接对象访问相应的数据存储。

在上面的实施例中，连接处理器内的每个内部连接池可以包括特定配置的任何数量的连接对象。一个特定内部连接池内的所有连接对象是同构的，即它们都具有相同的配置，因此结果是，连接处理器内的不同内部连接池可以将不同配置的同构连接对象的集合分组。一个或多个内部连接池是异构的，即每个内部连接池包括具有不同于其它连接池的配置的配置的的连接对象，以便向至少一个应用提供适合于不同数据存储(例如，具有不同数据库URL、用户名、密码等的不同物理数据库)的连接对象。

连接处理器还包括适合于与应用通信的接口。接口适合于从应用接收对于特定配置的连接对象的请求。为此，在本实施例中，在接口处接收的请求包括特定配置的连接对象的标识，例如，按照请求中包括的一个或多个参数的形式。因此，应用能够在它的请求中向连接处理器标识期望连接对象的属性，即，应用能够指定要从连接处理器获得的连接对象的期望特定配置。然后，连接处理器适合于经由它的接口向应用提供来自各个内部连接池的适当的连接对象(即满足所请求配置，即具有所请求属性的连接对象)。因为连接池在连接处理器内部，即封装在其中，并且因为应用仅仅经由连接处理器的接口与其通信，应用不必知道连接处理器的各个内部连接池并且优选地不能直接对其访问。

因此，应用能够首次获得特定配置的连接对象，而不必关注一个或多个连接池的数量、结构、配置等。这大大降低了应用获得特定配置的连接对象所需的努力，这导致效率增加以及应用内更简单并且因此更安全的代码。另一方面，因为各个连接对象内部地包括在连接处理器内，连接处理器能够以集中方式管理连接对象，这改进了连接池、其包括的连接对象以及连接的数据存储的整体资源利用。

在另外的方面中，连接处理器可以适合于取决于连接处理器是否已经包括相应的内部连接池的评估，在运行时期间创建专用于至少一个请求的新的内部连接池，其中连接处理器可以还适合于在处理了至少一个请求之后保持所创建的内部连接池。因此，如果连接处理器还没有包括具有匹配于请求的连接对象的内部连接池(即，不存在具有其配置匹配于应用的请求内指定的期望配置的连接对象的内部连接池)，连接处理器可以在运行时期间创建新的适当的内部连接池。换言之，在连接处理器已被配置时，连接处理器能够满足对于具有先天未知的配置的连接对象的请求。因此，连接处理器在运行时期间动态地适应做出请求的应用的需要。另外，一旦创建了新的内部连接池并且将相应的连接对象地送到做出请求的应用，连接处理器能够保持内部连接池，以使得来自相同或者另一应用的对于对应于新创建的内部连接池的连接对象的未来请求可以被立即处理。新的内部连接池的创建可以附加或者替代地依赖于对所有现有内部连接池中当前使用的连接对象的数量的评估和/或对在所有现有内部连接池中包括的连接对象的总数量的评估。

在本发明的又另一方面中，连接处理器可以还适合于在运行时期间从一个或多个内部连接池移除一个或多个现有的连接对象。这进一步改进了连接处理器的动态性质并且减少了资源使用，因为连接处理器可以不仅在运行时期间按需创建新的内部连接对象和池，而且还能够在运行时期间动态地移除某些连接对象，例如以便释放处理和存储资源。移除一个或多个现有连接对象可以包括移除最近最少使用的、最近使用的、最少使用的、和/或最近最不频繁使用的(the least frequently recently used)连接对象，将在下面的详细描述中进一步说明。而且，移除一个或多个现有的连接对象还可以依赖于对在所有现有内部连接池中包括的连接对象的总数量的评估。

在另一个方面中，评估在所有现有内部连接池中包括的连接对象的总数量可以包括评估在所有现有内部连接池中包括的连接对象的总数量是否超过了在配置连接处理器期间定义的预定义阈值。作为替代，预定义阈值可以在连接处理器运行时期间被定义和/或改变，以便例如使其适合于应用做出的增加数量的请求。因此，因为预定义阈值应用于所有内部连接池，连接处理器能够根据全局配置以集中方式管理不同的内部连接池。

附加或者替代地，连接处理器的接口还可以适合于从至少一个应用接收至少一个第二请求，其中至少一个第二请求不包括特定配置的连接对象的标识，并且其中接口还适合于向至少一个应用提供来自预配置的内部连接池的连接对象。因此，相比于特定地标识具有某种配置的期望连接对象的至少一个第一请求，至少一个第二请求不包括该信息，即它是没有指定至少一个应用期望连接对象的哪种配置的对于连接对象的请求。这具有如下优点：被编程用于访问现有技术的连接池的现有应用也可以使用本发明的连接处理器，而不必改变它们的代码。因此，本发明的连接处理器对于已知的连接池是向下兼容的。

在本发明的另一个方面中，可以用一组连接属性来配置每个内部连接池中的连接对象，并且其中在接口处接收的至少一个请求包括所请求的连接属性组。因此，连接处理器的内部连接池中的连接对象的特定配置可以包括对于各个连接对象连接的各个数据存储配置各个连接对象所需的任何信息。配置属性例如可以包括诸如数据库名称、用户名和/或密码这样的信息。在该方面中，来自至少一个应用的至少一个请求也可以直接指定所请求的连接属性组，例如请求的数据库名称、用户名和/或密码。因此，连接处理器可以选择其连接对象具有匹配于所请求的连接属性组的配置的相应内部连接池。替代地，至少一个请求可以仅包括所请求的连接属性的子集，例如，仅包括数据库地址和数据库名称，而没有用户名和密码。在该情况下，连接处理器可以对于在至少一个请求中未指定的连接属性(该示例中为用户名和密码)填充预定义的默认值。连接处理器然后可以从用相应属性配置的任何内部连接池选择连接对象。

此外，每个内部连接池中的连接对象可以用一组连接属性来配置，并且连接处理器可以适合于存储包括预定义的连接属性组的一个或多个别名，其中在接口处接收的至少一个请求包括一个别名。因此，在该方面中，至少一个请求不包括特定的连接属性组，而是仅仅包括别名，该别名是到优选地在配置连接处理器期间预定义的预定义连接属性组的引用。这具有如下优点：至少一个应用不必知道准确的连接属性，而是仅仅需要知道别名以便获得适当的连接对象。

在本发明的又另一方面中，连接处理器可以适合于存储涉及有关内部连接池的信息，其中更新一个内部连接池涉及更新所有有关的内部连接池。因此，连接组可以在将有关连接池分组的连接处理器内被定义。在某些场景中，例如，当连接的数据存储返回连接错误时，可能必须更新特定的连接池，即销毁全部或部分所包括的连接对象和重新创建连接对象。在该情况下，如果更新了特定的内部连接池，连接处理器能够基于所定义的连接组来确定有关的另外的内部连接池，并且还能够更新那些有关的连接池。可以用包括键/值对的一组连接属性来配置每个内部连接池，并且其中涉及有关内部连接池的信息包括键的子集，将在下面的详细描述中进一步说明。

本发明还涉及一种方法，该方法使用上述的任何一种连接处理器向至少一个应用提供多个异构连接对象中的至少一个。最后，提供了包括用于实现方法的指令的计算机程序。

附图说明

在随后的详细描述中，参考下面的附图进一步描述本发明的当前优选实施例：

图1：根据本发明实施例的连接处理器的示意性框图；和

图2-4：根据本发明实施例的由连接处理器执行的任务的流程图。

具体实施方式

在下面，针对图1示意性示出的连接处理器1来描述本发明的当前优选实施例。如可看到的，连接处理器1包括两个示例内部连接池30和31，其中连接池30包括三个示例连接对象300，并且连接池31包括三个示例连接对象301。因此，特定连接池内的连接对象是同构的，而连接池是异构的(即，每个连接池包括不同于其它连接池的连接对象)。应当注意，图1仅示出了非常简单的示例，并且连接处理器1可以包括可在运行时期间被动态创建和移除的任意数量的内部连接池30、31和连接对象300、301。连接处理器1还包括接口10，用于与示例应用2通信，例如Java应用。尽管连接处理器1通常能够经由接口10与任意数量的应用2通信，接口10优选地是一个或多个应用2和连接处理器1之间的唯一通信点。

在下面，将结合以下接口定义来描述单个连接池(例如内部连接池30、31中的一个)的接口：

如可看到的，操作getConnection()适合于从连接池取回连接对象。如果没有空闲的连接对象，即，连接池内所有的连接对象当前都被使用，并且如果连接池的当前大小小于所允许连接的最大数目，可以创建新的连接对象。否则，如果达到了连接池的最大尺寸，可以抛出异常，或者可以强迫调用方等待预定义的时间量。

应当注意，单个连接池的接口的上面的操作getConnection()不接受任何输入参数，因为连接池仅仅存储同构的连接对象。因此，getConnection()操作的调用方不能请求特定配置的连接对象，而是必须接受作为调用的响应由连接池提供的连接对象。因此，单个连接池适合于仅向调用方提供预先配置的连接对象，其中配置由连接池预先定义。操作releaseConnection(Connection conn)可以用于向连接池通知参数‘conn’所标识的连接对象被释放，即，它不再由调用方使用。然后，所标识的连接对象可以由连接池释放并且可以在随后被重用。操作getMaxConnections()适合于返回在任何时间点连接池内被允许存在的连接对象的最大数目。该数目在配置单个连接池期间被指定并且专用于该连接池。类似地，操作getMinConnections()适合于返回连接池中保持的连接对象的最小数目。操作size()适合于返回当前位于特定连接池内的连接对象的数目。依赖于具体的实现，连接池还可以包括另外的操作。当初始化连接池时，即在接收第一请求之前，它可以立即创建最少数目的连接对象，如由getMinConnections()操作所指定的。

在下面，结合以下示例接口规范来说明根据本发明实施例的连接处理器1的接口10：

如可看到的，当被请求时，连接处理器1的操作getConnection(Mapattributes)接受用于标识特定配置的连接对象300、301的输入参数‘attributes’。然后，操作可以返回匹配于请求的连接对象300、301，即按调用方期望所配置的连接对象300、301。在上面的示例中，输入参数按照包括键/值对的映射的形式。应用2可以在对连接处理器1的请求中调用操作getConnection(Map attributes)，其中请求可以包括用于属性键的具体属性值，以便获得特定配置的连接对象300、301。在某些实施例中，至少某些，优选地，全部的键可以被预定义并且专用于连接处理器1的实现。例如，在用于提供JDBC连接对象300、301的连接处理器1的示例实现中，键可以被定义为服务器IP地址、服务器端口和/或数据库名称。替代地，连接属性，即应用2在其请求中提供的键/值对可以是任意的并且完全由应用2确定。

此外，操作getMaxConnectionsPerGroup()可以适合于返回可为组创建的连接对象300、301(即，具有相同属性值的连接对象300、301)的最大数目。类似地，操作getMinConnectionsPerGroup(可以适合于返回为组维持的连接对象300、301(即具有相同属性值的连接对象300、301)的最小数目。优选地，这两个操作，即最大和最小数目阈值在连接处理器1中定义一次并且应用于每个单个的内部连接池30、31，以使得可以根据全局配置管理所有内部连接池30、31。

而且，接口10还可以包括不接受任何输入参数的操作getConnection()(未在上面的接口规范中描绘)。如果该操作在来自应用2的请求中被调用，操作可以根据默认配置，优选地从默认预先配置的内部连接池30、31返回连接对象300、301。这也可以适用于如下情况：当调用了操作getConnection(Map attributes)，但没有提供属性和/或属性值为空时。

最后，上面的接口规范示出了releaseConnection(Connection conn)操作，其用于从相应的连接池30、31移除特定的现有连接对象300、301(即输入参数conn表示的连接对象)。

在下面，更详细地描述本发明的连接处理器1的内部功能。已经在上面进一步说明，连接处理器1包括一个或多个内部异构连接池30、31并且因此可以理解为创建和维持异构连接池的池，其中每个池内部的连接对象是同构的。优选地，连接池30、31之一包括默认配置的连接对象300、301，其可由应用2通过调用连接处理器1的接口10的getConnection()操作(没有输入参数)来获得。另一方面，当接口接收了对于特定配置的连接对象300、301的请求(例如经由操作getConnection(Map attributes)时，连接处理器1将会从另外的内部连接池30、31之一服务该请求。如果没有包括适当连接对象300、301的内部连接池30、31，连接处理器1可以创建适合于提供所请求的配置的连接对象300、301的新的内部连接池30、31。然而，附加的内部连接池30、31的内部创建对于做出调用的一个或多个应用2来说是隐藏的。

内部连接池30、31中的每一个可以根据配置参数在运行时期间被动态地配置。在一个实施例中，连接池配置参数可以在连接处理器1中被被定义一次并且应用于所有的内部连接池30、31，以便实现所有内部池的全局配置。以下列出了示例的连接池配置参数：

-每组的最大连接：该参数指定了可为组创建的连接对象300、301(即具有相同配置的连接对象300、301)的最大数目，并且确定了可在一个内部连接池30、31内被创建的连接对象300、301的最大数目。该参数在图4的流程图中被示例性地称作为MAX_SIZE_PER_GRP。

-每组的最小连接：该参数指定了在每个内部连接池30、31中维持的连接对象300、301的最小数目。该参数在下面被示例性地称作为MIN_SIZE_PER_GRP。在优选实施例中，最初在连接处理器1初始化时不创建最小数目的连接对象300、301，因为在该时间点，连接对象300、301的配置通常是未知的。相反，由应用2经由它们的请求确定由连接处理器1在运行时期间创建哪些特定配置的连接对象300、301和相应的内部连接池30、31。

此外，连接处理器1可以包括另外的全局配置参数：

-最大池尺寸：该参数指定了可以在整个连接处理器1中，即在所有的内部连接池30、31中创建的连接对象300、301的最大数目。该参数在图3和4的流程图中示例性地称作为MAX_POOL_SIZE。一旦超过该阈值，连接处理器1可以移除一个或多个现有的内部连接池30、31和/或连接对象300、301，将在下面进一步详细说明。

在下面，将参考图2到4的流程图更详细地描述连接处理器1的各种有利特征。将会理解，可以提供仅仅支持某些下面给出的特征的连接处理器1的各个实施例，而仍然实现它们各自的优点。

图2示出了当从应用2接收请求时由连接处理器1执行的处理。处理在步骤100开始，并且进行到判定步骤101。

在步骤101，判定请求是否针对于特定配置的连接对象300、301，即判定连接对象300、301是要从默认的内部连接池30、31提供还是要从特定配置的内部连接池30、31提供。在一个实施例中，当调用没有输入参数的操作getConnection()时，使用默认的内部连接池30、31。这也适用于如下情况：当调用操作getConnection(Map attributes)，但没有提供属性的值时，和/或当所提供的属性等同于默认内部连接池30、31的属性时。

如果是这种情况，在步骤103中，从默认内部连接池30、31取回连接对象300、301并且将其返回给做出调用的应用2。如果在默认内部连接池30、31中不存在连接对象300、301，在将连接对象300、301地送到做出请求的应用2之前在步骤103中创建它。

如果在步骤101中判定请求是对于特定配置的连接对象300、301的请求，连接处理器1进行到判定步骤102并且判定是否已经存在适合于满足请求的内部连接池30、31(例如，通过比较所请求的连接属性组和现有内部连接池30、31的连接属性组)。

如果在步骤102中标识了适当的内部连接池30、31，连接处理器1进行到步骤105并且判定相应的所标识内部连接池30、31是否具有任何空闲的连接对象300、301(即，是否已经存在当前未被使用的连接对象300、301)。如果是，在步骤106中取回相应的连接对象300、301并且将其提供给做出调用的应用2。

如果在步骤105中没有标识出空闲的连接对象300、301，连接处理器1进行到步骤108(参照图4)并且判定所标识内部连接池30、31内当前存在的使用中的连接对象300、301的数目是否小于每组可允许的连接对象300、301的最大数目(参照上面说明的参数MAX_SIZE_PER_GRP)。如果不是，不能创建连接对象300、301(步骤112)并且处理在步骤113结束。通常，连接处理器1可以为此在当前使用的(即，由应用2用于连接到某个数据存储)或当前未使用的(即，应用2已完成对连接对象的使用并且将它返回到连接处理器1)已经创建的连接对象300、301之间进行区分。

否则，判定步骤210判定整个连接处理器1中当前存在的使用中的连接对象300、301的总数目是否小于整个连接处理器1中，即其所有的内部连接池30、31中可允许的连接对象300、301的最大数目(参照上述的参数MAX_POOL_SIZE)。如果不是，不能创建连接对象300、301(步骤112)并且处理在步骤113中结束。

否则，判定步骤109确定整个连接处理器1中当前存在的连接对象300、301的总数目(即空闲或是在使用的连接对象的数目)是否小于整个连接处理器1中，即其所有内部连接池30、31中的可允许连接对象300、301的最大数目(参照上面说明的参数MAX_POOL_SIZE)。如果是，在步骤110中连接管理器1在所标识的内部连接池30、31中创建新的连接对象300、301并且将新创建的连接对象300、301提供给做出调用的应用2。

如果不是，连接管理器1可以在步骤114中从内部池30、31移除现有的连接对象300、301之一(进一步参见下面)并且随后进行到步骤110。

如果步骤102中的评估(参照图2)判定不存在任何适合于处理请求的内部连接池30、31，连接处理器进行到步骤201(参照图3)并且判定使用中的连接对象300、301的总数目是否小于允许的最大值(参照上面说明的参数MAX_POOL_SIZE)。如果不是，不能创建连接对象300、301(步骤204)并且处理在步骤205结束。

否则，连接处理器进行到步骤115(参照图3)并且判定连接对象(使用中和空闲的)300、301的总数目是否小于允许的最大值(参照上面说明的参数MAX_POOL_SIZE)。如果是，连接处理器1在步骤116中创建专用于请求的新的内部连接池30、31，即适合于提供满足请求的连接对象300、301的新的内部连接池30、31。然后，在步骤202中连接处理器1在所标识的内部连接池30、31中创建新的连接对象300、301，并且将新创建的连接对象300、301提供给做出调用的应用2。

如果步骤115中的评估判定整个连接处理器1中已存在的连接对象300、301的总数量等于允许的阈值(参照上面说明的参数MAX_POOL_SIZE)，连接处理器1可以在步骤117中从内部连接池30、31移除现有的连接对象300、301中的一个，并且随后进行到步骤116。

在下面，将描述用于从内部连接池30、31移除114、117连接对象300、301的策略的有利变化。将会理解，依赖于应用的使用情况，可以利用另外的策略。此外，如果影响连接对象300、301重用的条件是预先知道的，连接处理器1可以用适当的预定义移除策略来实现。另外，例如如果要在适合于连接到各种不同的数据存储的应用服务器上使用连接处理器1，可以由管理员在运行时和/或连接处理器配置时期间选择适当的移除策略。下面是移除策略的示例：

-最近最少使用(LRU)：根据该策略，移除在某时间周期内未被处理的连接对象300、301。时间周期可以由连接处理器1的适当配置参数来确定。当应用2常常重用它们最近使用过的连接对象300、301时，该策略尤其有利。

-最近使用(MRU)：根据该策略，首先移除最近使用的连接对象300、301。在大部分近来被访问的连接对象300、301在近期不会被频繁重用，但是连接越早，它越可能要被访问的情况下，该策略是尤其有利的。

-最少使用(LFU)：根据该策略，被使用的时间量最少的连接对象300、301被移除。在该策略中，连接处理器1可以维持一个或多个计数器，以判定单个连接对象300、301被请求得多频繁。当某些连接对象300、301相比于其它的被更频繁地使用，以使得计数器可以用作为连接对象300、301在将来被重用的可能性的指示时，该策略是特别有利的。该策略的另外的变化时“老化LFU”，其相比于较早的使用更多地考虑近来的使用。

-最近最不频繁使用(LFRU)：该策略移除最少使用和近来未使用的连接对象300、301，由此组合了LRU和LFU策略，这可导致改进的性能。

在下面，将描述示例应用场景，其中本发明的连接处理器1是特别有利的。例如，应用2可以设计为使用消息机制，例如MQ消息，用于处理来自应用2的多个不同用户的请求消息。在处理消息之后，应用2会将相应的响应消息发送到做出请求的用户。在该示例中，所有用户将他们的请求消息插入到在配置时间期间对应用2来说已知的预定义请求队列。然而，用于响应消息的对应响应队列将是专用于应用2的每个用户的并且优选地在用户环境中运行。因此，在配置时响应队列对于应用2来说是未知的，并且因此对于应用2期望使用的连接处理器1来说也是未知的。响应队列属性，例如队列服务器地址、端口、队列管理器名称、队列名称和/或通道名称，将是未知的，直到做出调用的用户在他们的请求消息中，即在运行时，指定这些属性为止。因此，应用2需要对于不同的用户请求使用不同的连接对象，这通过上述的连接处理器1的有利特征来实现。

在另一个有关的应用场景中，应用2期望将用于用户的数据通知到用户数据库的相应表格。然而，数据库连接属性，例如服务器地址、端口、模式名称、用户和/或密码，对于每个用户来说将是不同的，并且因此应用2需要对于每个用户使用具有不同配置，即连接属性的不同连接对象。而且在这里，应用2可以通过使用本发明的连接处理器1来有利地完成该任务。

在某些实施例中，连接处理器1可以附加或者替代地具有将内部连接池30、31的配置，例如有关的连接属性与组关联的能力。因此，在连接处理器1的配置期间，可以指定哪些连接参数作为所谓的连接组的一部分。在下面，使用为JDBC连接对象配置的连接处理器1的池更新特征来给出示例。通常，如果当创建连接时或者当执行事务时出现任何连接失败，更新连接池(即，池内的所有连接对象被销毁和重新创建)。连接失败的示例原因可以是网络故障或数据库无效。

在示例中，连接属性，即连接处理器1的内部连接池30、31的具体配置包括属性数据库服务器地址(SERVER_IP)、数据库服务器端口(PORT)、数据库名称(DATABASE_NAME)、用户名(USER)和密码(PASSWORD)。在该示例中，连接组可以定义为仅包括属性SERVER_IP、PORT和DATABASE_NAME，即上面的连接属性的子集。如果连接处理器1需要更新它的内部连接池30、31，仅仅需要更新这样的内部连接池30、31：该内部连接池30、31具有的连接对象300、301有相同的SERVER_IP、PORT和DATABASE_NAME的值，因为它们连接到相同的物理数据库服务器。注意，USER和PASSWORD不包括在示例连接组中，因为即使(位于不同的内部连接池30、31内的)两个连接对象300、301的USER属性不同，但是如果它们都连接到相同的数据库服务器，在连接失败的情况下需要更新这两个连接对象300、301。

类似地，在另一个示例中，适合于为MQ消息(参见上面)维持内部连接池30、31的连接处理器1可以包括具有属性MQ服务器地址、端口、队列管理器名称和连接通道的连接组。因此，池更新将影响具有上面属性的相同值的所有连接对象300、301，即使例如队列名称或其它另外的连接属性不同。

总的来说，连接组的特征具有这样的优点：基于连接属性值有效地控制连接处理器1的生命周期管理活动，例如池更新、连接期满、控制连接对象的最小和最大数目、等等。

本发明的连接处理器1还可以具有使用别名预定义连接参数的子集的能力。当在配置连接处理器1时已经知道连接属性的一部分的情况下，这尤其有利。然后，在运行时期间，应用2可以基于某些动态属性的值来请求连接对象300、301，将在下面更详细地说明。

在下面的示例中(也参见上面另外的示例应用场景)，应用2期望将用于用户的数据通知到用户数据库的相应表格。应用2可能需要到每个用户数据库的连接。在该示例中，存在都使用不同数据库的固定的预定义数目的用户。

现有技术中已知的方法是在应用2中对于每个用户配置不同的连接池。那么应用2将必须在运行时期间标识要使用哪个连接池，例如基于用户和连接池之间的映射。然而，这显然是耗费劳动并且易于出错的，并且大大增加了需要由应用2执行的管理任务的开销。

相反，如果应用2使用本发明的连接处理器1的一个实施例，优选地在配置时间期间，可以在连接处理器1中定义一个或多个别名，其中每个别名是一组连接属性和/或对应值的定义。在上面给出的示例场景中，别名中的连接属性之一可以是相应用户的ID、数据库服务器地址、数据库名称、用户名和/或密码，优选地专用于每个单个用户。要注意，上面已经另外描述的另外连接处理器的配置属性(例如允许的连接的最大/最小数目、期满时间、等等)对于所有别名来说可以是相同的，并且因此在连接处理器1中被全局地定义。

在运行时期间，当应用2从用户接收请求时，应用2通过发送包括特定配置的连接对象的标识的请求，例如通过调用连接处理器1的接口10提供的操作getConnection(String aliasname)，仅仅使用单个连接处理器1。当这么做时，应用2将对应于做出请求的用户的别名插入到getConnection操作的输入参数中并且连接处理器1可以根据别名定义判定相应的连接属性。在一个实施例中，当定义别名时，别名可以是用户ID。然后，在运行时期间，应用2可以调用操作getConnection(String aliasname)，相应的userid作为别名。另一种方式是在设计时间期间，当配置别名时将userid作为属性并且为其指定值。然后，应用2可以使用操作getConnection(Mapattributes)来通过将userid传递到属性中而获得连接对象300、301。

总的来说，上述的本发明的连接处理器1的各种特征提供了这样的优点：做出调用的应用2仅仅需要知道一个单个连接处理器1，而不是如现有技术中那样要知道多个不同连接池，这导致了应用2中的开销大大减少，并且由此增加了它们的性能。而且，另外的优点在于，可以显著优化整体资源使用，因为连接处理器1的配置属性(例如允许的连接的最大/最小数目)优选地应用于整个连接处理器1所维持的所有内部连接池和连接对象，使得连接处理器1能够以集中方式管理内部连接池30、31。

Claims (14)

1.一种连接处理器(1)，用于向至少一个应用(2)提供多个异构连接对象(300、301)中的至少一个，其中所述连接处理器(1)包括：

a.一个或多个异构内部连接池(30、31)，其中每个内部连接池(30、31)适合于提供除了其它内部连接池(30、31)的配置之外的特定配置的同构连接对象(300、301)；和

b.接口(10)，适合于从所述至少一个应用(2)接收至少一个请求，其中所述至少一个请求包括特定配置的连接对象(300、301)的标识，并且其中所述接口(10)还适合于作为响应向所述至少一个应用(2)提供来自相应内部连接池(30、31)的连接对象(300、301)。

2.根据权利要求1所述的连接处理器(1)，适合于取决于所述连接处理器(1)是否已经包括相应的内部连接池(30、31)的评估(102)，在运行时期间创建(106)专用于所述至少一个请求的新的内部连接池(30、31)，其中所述连接处理器(1)还适合于在处理了所述至少一个请求之后保持所创建的内部连接池(30、31)。

3.根据前一权利要求所述的连接处理器(1)，其中所述新的内部连接池(30、31)的创建(116)还依赖于对所有现有内部连接池(30、31)中当前使用的连接对象(300、301)的数量的评估(201)和/或对在所有现有内部连接池(30、31)中包括的连接对象(300、301)的总数量的评估(115)。

4.根据前述权利要求中任一项所述的连接处理器(1)，还适合于在运行时期间从所述一个或多个内部连接池(30、31)移除(114、117)现有的连接对象(300、301)中的一个或多个。

5.根据前一权利要求所述的连接处理器(1)，其中移除(114、117)现有连接对象(300、301)中的一个或多个包括移除最近最少使用的、最近使用的、最少使用的、和/或最近最不频繁使用的一个或多个连接对象(300、301)。

6.根据权利要求4或5所述的连接处理器(1)，其中移除(114、117)现有的连接对象(300、301)中的一个或多个依赖于对在所有现有内部连接池(30、31)中包括的连接对象(300、301)的总数量的评估(109、115)。

7.根据权利要求3或6所述的连接处理器(1)，其中所述评估(109、115)包括评估在所有现有内部连接池(30、31)中包括的连接对象(300、301)的总数量是否超过了在配置所述连接处理器(1)期间定义的预定义阈值。

8.根据前述权利要求中任一项所述的连接处理器(1)，其中所述接口(10)还适合于从所述至少一个应用(2)接收至少一个第二请求，其中所述至少一个第二请求不包括特定配置的连接对象(300、301)的标识，并且其中所述接口(10)还适合于向所述至少一个应用(2)提供来自预配置的内部连接池(30、31)的连接对象(300、301)。

9.根据前述权利要求中任一项所述的连接处理器(1)，其中用一组连接属性来配置每个内部连接池(30、31)中的所述连接对象(300、301)，并且其中在所述接口(10)处接收的所述至少一个请求包括所请求的一组连接属性。

10.根据前述权利要求中任一项所述的连接处理器(1)，其中用一组连接属性来配置每个内部连接池(30、31)中的所述连接对象(300、301)，其中所述连接处理器(1)适合于存储包括预定义的一组连接属性的一个或多个别名并且其中在所述接口(10)处接收的所述至少一个请求包括所述别名之一。

11.根据前述权利要求中任一项所述的连接处理器(1)，适合于存储标识一个或多个有关内部连接池(30、31)的信息，其中更新所述内部连接池(30、31)之一涉及更新所有有关的内部连接池(30、31)。

12.根据前一权利要求所述的连接处理器(1)，其中用包括键/值对的一组连接属性来配置每个内部连接池(30、31)，并且其中标识一个或多个有关内部连接池(30、31)的所述信息包括所述键的子集。

13.一种方法，用于使用根据前述权利要求中任一项所述的连接处理器(1)向至少一个应用(2)提供多个异构连接对象(300、301)中的至少一个。

14.一种计算机程序，其包括用于实现根据前一权利要求所述的方法的指令。

Images