专利名称：有状态程序实体的工作负荷管理的制作方法
技术领域：
本发明涉及维护易失性存储器中的状态的程序实体的工作负荷管理，具体来说，涉及诸如Enterprise JavaBeansTM体系结构的有状态会话bean之类的对象的重新定位。
背景技术：
在客户端-服务器企业系统中进行工作负荷管理现在是普遍现象。在工作负荷管理系统中，设置一组服务器进程(工作组)，以便工作组中的每一个服务器进程都具有类似的能力。这使得工作组中的每个服务器进程都代表客户端处理给定的请求(或消息)。当客户端向工作组发送请求时，工作负荷管理单元决定将请求分配给工作组中的哪一个服务器进程。这通常基于用户定义的策略，这种策略可以是，最不忙或循环复用。这样就有希望确保，有效地使用服务器进程资源，客户端由于单服务器进程同时为许多客户端运行请求所引起的瓶颈而造成的响应速度较慢的可能性较小。
图1显示了一个典型的工作负荷管理系统。该系统包括许多客户端通过网络(11)与工作负荷管理单元(12)进行通信的许多客户端(10)。工作负荷管理单元(12)通过网络(11)向包括两个服务器进程的工作组分配工作，每一服务器进程都在服务器(13和14)中运行。当客户端发出请求时，工作负荷管理单元接收该请求，并选择服务器进程，以便将请求分配给该服务器进程。工作负荷管理单元可以是组成工作组的一个或多个服务器进程的一部分。
在理想的情况下，在这样的系统中，工作负荷管理单元基于所选择的策略为接收到的每一个客户端请求随意选择服务器进程，因为，这样能够更好地分配工作。然而，这并不总是可以实现的。例如，在一个请求中，客户端可以在一个给定服务器进程中创建一个对象实例，而该服务器进程包含客户端在随后的请求中需要访问的数据。为使客户端正确地工作，工作负荷分配单元必须确保客户端可以访问正确的对象实例。这可以这样来实现，通过在客户端的寿命内维护客户端-服务器关系的某些元素，以确保，当客户端以后需要访问在其中创建了对象实例的服务器进程时，客户端能够返回到该服务器进程，或者通过使对象实例能在响应不同请求时在各个服务器进程之间移动，而不会改变状态。如果唯一可用的选项是客户端-服务器关系，那么，工作负荷分配将受到不利的影响，因为唯一可以做到的是对客户端请求的子集进行工作负荷管理，如果说预测当客户端-服务器关系被固定时客户端施加于服务器进程的负荷不是不可能的话，也是比较困难的。
因此，优选情况下，最好能使对象在请求之间移动服务器进程。对于维护数据库(或文件)中的状态数据的对象是相当简单的，因为对象实例可以从工作组中的任何服务器进程访问数据库或文件。结果，对象实例可以移到任何服务器进程中，虽然如果它参与事务，则在事务完成之前对象无法移动，因为在事务期间进行的数据库更改只有在事务提交之后才被加固到数据库。然而，如果对象实例保留易失性存储器中的状态数据，则它无法轻易地在服务器进程之间移动。这是因为，易失性存储器通常只能从分配它的服务器进程进行访问。结果，如果客户端使用这种类型的对象，则实施客户端-服务器关系，工作负荷管理将受到所讨论的限制。
这可以通过查看在这样的工作负荷管理客户端-服务器企业系统中使用的特定的编程模式来进行说明。一个好的示例是行业标准Enterprise JavaBeansTM(EJBTM)编程模式。此模式在SunMicrosystems，Inc.推出的Enterprise JavaBeans v1.1规范中进行了全面的定义，该规范在这里进行了引用。为清楚起见，现在描述此规范的某些特点。
Enterprise JavaBeans v1.1规范基于EJB对象的功能描述了在服务器进程中运行的EJB(对象)的分类。两个类别是会话bean和实体bean。会话bean通常代表客户端执行；可以访问数据库但不代表数据库；寿命短；不可恢复。实体bean通常对多个客户端可访问；代表数据库；寿命长；可恢复。会话bean进一步可以分类为无状态的或有状态。无状态会话bean实例不包含会话状态，以便客户端可以使用会话bean的任何实例。然而，有状态会话bean实例却包含客户端可能需要重复访问的会话状态。结果，客户端必须始终访问具有所需的状态的有状态会话bean的实例。由于此状态至少部分地保留在易失性存储器中，这通常需要客户端始终访问有状态会话bean的同一实例。
EJB容器为EJB在服务器进程中提供了一个执行环境。Enterprise JavaBeans v1.1规范指定了客户端和容器以及EJB和其容器之间的合同。容器和客户端之间的合同的一部分是为EJB提供一个宿主，客户端可以进入到其中，以创建新的EJB实例并定位现有的EJB实例。EJB和其容器之间的合同的一部分指定了EJB必须实现的方法，以便使容器能够给bean实例提供对容器服务的访问，并向bean实例发出通知。这些方法随着bean的类型而变化。例如，有状态会话bean必须实现的两个方法是ejbActivate()和ejbPassivate()。当容器即将通过序列化bean实例并将它写入到磁盘中来钝化bean实例时，在bean实例上调用ejbPassivate()。这可以由于种种原因来进行，如，bean在其中被实例化的服务器进程的内存容量低和/或bean实例在指定的时间段内没有被访问。然而，由于会话bean可以被事务识别，当bean实例参与事务时，容器无法钝化bean实例。在ejbPassivate()方法中，bean实例必须确保，至少部分地保留在内存中的其会话状态，可以不被钝化，因此，例如，它必须关闭它打开的任何JDBCTM连接。一旦bean实例被钝化，可以通过从磁盘中读取其序列化的形式，解除其序列化，然后调用其ejbActivate()方法来重新活化。结果，在ejbActivate()方法中，bean实例可以重新打开任何在钝化期间被关闭的JDBC连接。
图2是所描述的EJB编程模式的略图。它显示了提供EJB容器(201)的EJB服务器进程(20)。对于每一个实现的EJB，提供了EJB宿主(202)，该宿主可以被客户端(10)用来创建该EJB(203)的实例。EJB服务器进程(20)可以为许多EJB实现提供宿主。EJB实例(203)在EJB容器(201)提供的环境中执行，一旦创建实例，客户端(10)就可以向它发送请求。随时都可能有相同或不同的客户端创建的EJB的许多实例(204，205)。
图3a和3b是有状态会话bean钝化和重新活化的略图。图3a显示了在易失性存储器中维护bean的计数器的名为BeanCounter的有状态会话bean的实例。在钝化期间，Deancounter实例(302)从EJBServer(20)中的易失性存储器中删除，并以其序列化的形式(304)写入到磁盘上的bean存储区中(303)。序列化的形式包含BeanCounter实例(302)的会话状态(beans＝5)。BeanCounter实例(302)是以虚线绘制的，以表示，它已经从易失性存储器中删除，并且在结束钝化时，它只以其序列化形式(304)存在于磁盘之中。图3b显示了重新活化，这是钝化的相反过程。从磁盘中读取bean实例(304)的序列化形式，并作为Beancounter实例(302)重新活化。在重新活化之后，实例存在于易失性存储器中，并包含在钝化之前它包含的会话状态(beans＝5)。在此过程之后，bean实例(304)的序列化形式可以也可以不必存在于磁盘中。
现在可以看出，在使用EJB编程模式的工作负荷管理系统中，工作负荷管理单元必须对客户端以前访问的EJB的类型敏感。例如，如果客户端只访问无状态会话bean实例，那么，来自客户端的任何请求都可以由工作负荷管理单元基于所选择的分配策略，分配给工作组中的任何服务器进程。这是因为，这些bean不包含会话状态。如果客户端访问实体bean实例，则它们还可以移动服务器进程，但只能在事务之间进行，因为实体bean在数据库保持状态并且是事务性的。然而，如果客户端创建并访问有状态会话bean实例，由于实例可以在易失性存储器中包含会话状态，客户端在客户端的寿命内将保持与在其中创建bean的服务器进程的关系，以便来自客户端的所有随后的发往bean实例的请求都被给予相同的服务器进程。如果bean在请求之间被钝化，则当接收到钝化之后的第一个请求时，bean在服务器进程中被重新活化。
提供使用EJB编程模式的工作负荷管理系统的产品的一个示例是BEA Systems，Inc.的BEA Weblogic ServerTM6.0产品。该产品将工作组叫做服务器群集。以两种形式提供工作负荷管理。EJB宿主对象可以具有识别群集的宿主存根，该存根了解群集中的所有服务器进程上的所有EJBHome对象。此存根为客户端请求提供工作负荷平衡，以创建和查找EJB实例。EJB可以具有识别副本的EJBObject存根，该存根了解驻留在群集中的服务器进程的EJB的所有副本。EJBObject存根为EJB方法调用提供负载平衡和故障转移服务。无状态会话bean可以是识别副本的，并具有识别群集的宿主，以便创建和访问无状态会话的所有请求的工作负荷都可以得到管理。然而，有状态会话bean只能具有识别群集的宿主，因此只有创建有状态会话bean的调用的工作负荷才可以得到管理。到有状态会话bean实例的所有请求一般来说被给予相同的服务器进程。使用有状态会话bean实例的内存中的复制提供了这一情况的例外。对于内存中的复制，有状态会话bean被给予削减识别副本的对象存根，该存根bean实例维护了在上面运行的主服务器进程实例，以及一个辅助服务器进程实例，以便用于复制bean的状态。现在如果客户端在事务的范围内修改bean实例的状态，当事务被提交时，bean实例的状态在辅助服务器进程中的易失性存储器中复制。万一bean实例的主服务器进程发生故障，则客户端请求被重新路由到辅助服务器进程，该辅助服务器进程变成主服务器进程，并从群集中分配一个新的辅助服务器进程。在此情况下，客户端自动获得对bean的最后一个提交的状态的访问。这为有状态会话bean提供了故障转移支持而不是工作负荷管理，并需要服务器协调bean实例的内存中的副本的删除。还可以看出，如果有状态会话EJB实例在未完成的事务中被修改，当主服务器发生故障时，到EJB实例的下一个请求将不会失败，但会丢失未提交的更改。结果，客户端永远不会知道有状态会话bean实例是否丢失未提交的更新。
发明内容
因此，需要提供用于包含易失性存储器中保留的状态数据的程序实体的工作负荷管理。
根据第一个方面，本发明提供了一种用于在数据处理系统上运行的数据处理方法，所说的数据处理系统具有非易失性存储器存储设备，该方法包括下列步骤作为服务器进程的一部分，通过将程序实体的实例写入到所说的存储设备上的程序实体存储区，并从所说的服务器进程中将其删除，来钝化所说的程序实体的实例；作为服务器进程的一部分，通过从所说的程序实体存储区读取所说的程序实体的实例，并在所说的服务器进程中重新创建它，来重新活化所说的程序实体的实例；其中，钝化以及随后重新活化所说的特定程序实体实例的服务器进程是不同的，其特征还在于根据工作负荷分配算法选择在其中重新活化特定程序实体实例的服务器进程。
根据第二个方面，本发明提供了一种用于执行上文描述的数据处理方法的计算机程序产品。
根据第三个方面，本发明提供了一种数据处理系统，包括至少一个服务器；许多能够在所说的至少一个服务器上运行的服务器进程，其中每个服务器进程都支持程序实体；以及每一个服务器进程都可以访问到的非易失性存储器存储设备；其中每一个服务器进程都包括用于通过将所说的程序实体的实例写入到所说的存储设备上的程序实体存储区来钝化所说的程序实体的实例的装置；以及用于通过从所说的程序实体存储区读取所说的程序实体的实例，并使用它来重新创建所说的程序实体实例，来重新活化所说的程序实体的实例的装置；其中，重新活化的装置可以重新活化被不同的服务器进程的钝化装置钝化的程序实体实例，其特征还在于，用于根据工作负荷分配算法选择在其中重新活化所说的特定程序实体实例的服务器进程的装置。
如此，本发明能使维护易失性存储器中的状态数据的程序实体的实例通过在一个服务器进程中钝化并在第二个服务器进程中重新活化来在服务器进程之间移动。结果，如果实体在请求之间移动服务器进程，则访问程序实体实例的请求可以受到工作负荷管理，由工作负荷管理单元选择它所移向的服务器进程。由于钝化步骤将程序实体实例的序列化形式写入到磁盘，而重新活化步骤在重新创建程序实体实例时解除序列化形式的序列化，因此，程序实体的状态数据得到维护。
优选情况下，为其提供工作负荷管理支持的程序实体是Enterprise JavaBean规范的有状态会话bean的实例。结果，如Enterprise JavaBeans所描述的，钝化和重新活化涉及ejbPassivate()和ejbActivate()。或者，程序实体也可以是Java bean或C++对象的实例。
优选情况下，本发明进一步为涉及程序实体实例的工作单元提供了工作负荷管理。工作单元将诸如请求之类的一个或多个事件分隔为单个的单元。优选情况下，工作单元是CORBA对象事项服务事务。或者，工作单元可以是，不同类型的事务，会话、业务方法、IBM CICS工作单元或客户端请求。另一种类型的事务的示例是Java事务API事务。这是通过在所选的工作单元完成时，而不是在此期间钝化程序实体来实现的。
优选情况下，本发明进一步向客户端提供保证，在诸如事务之类的一个工作单元下访问的程序实体实例，在工作单元完成之前，无法超出工作单元的范围之外重新访问。结果，如果工作单元由于在其中执行的服务器进程发生故障而不能完成，则程序实体实例将停止存在。这可以通过确保程序实体实例在重新活化期间从程序实体存储区删除来实现。
优选情况下，提供了包含可用于定位程序实体实例的信息的路由表。程序实体实例在为程序实体提供支持的许多服务器进程中的任何一个服务器进程中是活化的，或者，在不同的时间在bean存储区中是钝化的。然后可以在收到访问程序实体实例的请求之时使用路由表，将请求定向到程序实体当前在其中是活化的的服务器进程中，或如果程序实体当前是钝化的，则定向到任何服务器。程序实体存在于程序实体存储区中可以由路由表中没有与程序实体相关的项来表示。
优选情况下，减少对路由表的访问。如果与程序实体实例关联并用于将程序实体标识为请求的目标的键包括一个标志，表示程序实体实例的位置信息在路由表中存在，就可以实现这一点。然后，在收到入站请求之时，可以使用这一标志决定是否在路由表中查找bean实例的位置。例如，与有状态会话bean实例关联的键可以包括表示bean实例参与到不完整的bean管理事务中的标志。这可能是路由表将包括bean实例的位置信息的唯一情况，因此，当接收到一个bean实例请求时，只需要搜索路由表，查看其中bean实例是否设置了bean管理的标志。
下面将参考下面的附图，对本发明的优选实施例进行描述图1是优选情况下应用了本发明的优选实施例的数据处理环境的方框图；图2是与本发明有关并在优选情况下应用了本发明的Enterprise JavaBeans功能的略图；图3a和3b分别是根据Enterprise JavaBean规范的有状态会话bean钝化和重新活化的略图；图4a和4b是本发明的优选实施例中的主要部件之间涉及的流程的顺序图；图5是本发明的优选实施例的略图；图6是根据本发明的优选实施例的在磁盘上保存的能进行有状态会话bean的工作负荷管理的信息类型的说明图；以及图7是根据本发明的优选实施例的当向服务器分配入站请求时工作负荷管理单元所遵循的逻辑的流程图。
具体实施例方式
图1显示了优选情况下应用了本发明的优选实施例的数据处理环境。在该图中，客户端数据处理设备(10)通过网络(11)连接到工作负荷管理单元设备(12)，网络可以是因特网。客户端向工作负荷管理单元设备(12)发送请求(或消息)，工作负荷管理单元设备(12)通过网络(11)向数据处理服务器Server1(13)和Server2(14)分配请求，其中每一个服务器都包括处理这些请求的服务器进程。Server2(13)和Server2(14)的服务器进程能够处理等效的请求并构成一个工作组。虽然在此实施例中工作组包括两个服务器进程，每一个服务器进程都来自不同的数据处理服务器，但是，在其他实施例中，数据处理服务器可以包括一个或多个服务器进程，工作组可以包括来自一个或多个数据处理服务器的两个或更多服务器进程。
Server1(13)具有用于控制服务器的操作的处理器(131)，用于临时存储诸如有状态会话bean的存储器中的实例之类的数据的易失性存储器元件(132)，用于存储诸如钝化有状态会话bean的序列化形式之类的数据的非易失性存储器(133)，以及用于与网络(11)进行连接的网络连接器(134)。虽然未显示，但是，客户端(10)、工作负荷管理单元(12)和Server2(14)由与Server1的相同组件(131、132、133、134)构成，至少一个服务器的非易失性存储器(133)必须能够被工作组中的其他服务器访问。值得注意的是，在优选实施例中，虽然工作组由两台服务器组成，但是，在其他实施例中，工作组可以由两台以上的服务器构成。也是在优选实施例中，与构成工作组的服务器(13和14)分开显示了客户端(10)和工作负荷管理单元(12)，但是，在其他实施例中，这些设备中的一个或多个也可以是工作组中的服务器。此外，在优选实施例中，Server1(13)包括单个组件(131、132、133、134)，但是，在其他实施例中，可以有这些元件中的一个或多个，相反，工作组中的一个或多个服务器也可以共享这些组件。
在优选实施例中工作组提供了Enterprise JavaBeans编程模式的支持，同样也提供了有状态会话bean的支持；提供的事务服务是与CORBA兼容的对象事务服务(OTS)；工作负荷管理单元提供了事务关系的支持，以便在一个给定事务下的所有请求都由工作组中的相同的服务器进程进行处理。
图4a和4b显示了，根据本发明的优选实施例，可以从在两个单独的客户端启动的事务的范围内创建并访问一个给定有状态会话的bean的客户端产生的流程的序列。然而，请注意，所显示的流程只是将实际发生的与优选实施例有关的流程的子集。在此示例中，给定有状态会话bean是BeanCounter bean，该bean可以由客户端用来在客户端的寿命内统计bean。虽然这好像是一个有点过分简单的有状态会话bean，但是，bean统计确实具有保留在内存中的会话状态，完全可以适合用于此描述。然而，值得注意的是，本发明同样可以应用于在实践中可能比较复杂并也可以访问数据库中的数据的任何给定的有状态会话bean实例。
图4a显示了客户端的第一个事务的处理过程。客户端(401)发出开始事务请求(403)，工作负荷管理单元(未显示)将该请求分配给EJBServer1(402)中的事务服务，并建立事务与此服务器进程的关系。在事务被启动之后，客户端定位BeanCounter宿主，并向它发送一个创建请求(404)。工作负荷管理单元向EJBServer1(402)分配此请求，以维护事务-服务器关系，BeanCounter宿主用bean＝0的初始状态实例化新(405)BeanCounter实例。在从创建请求返回之前，知道在事务下创建BeanCounter实例的容器，发出register_synchronization请求(406)以向事务服务注册同步对象所拥有的容器。这将确保，在事务完成处理期间用after_completion调用容器。当客户端发出将bean状态更新到beans＝1的增量请求(407)时，客户端访问BeanCounter实例。工作负荷管理单元还将此请求分配到EJBServer1(402)以维护事务-服务器关系。当客户端即将完成事务时，它向事务服务发出提交请求(408)，该请求作为容器注册的同步对象上的提交处理调用after_completion(409)的一部分。然后，此对象调用BeanCounter实例上的ejbPassivate(410)，因为，根据本发明，在事务的范围内访问的有状态会话bean实例在该事务完成时被钝化。在此示例中，BeanCounter实例在ejbFassivate中无事可做，因为它没有打开的JDBC连接，其状态是可序列化的。在调用ejbPassivate之后，容器序列化BeanCounter实例，将它从易失性存储器中删除，并将它写入(411)到bean存储区。bean存储区不可恢复，保留在非易失性存储器中，在优选实施例中，非易失性存储器是一个硬盘。在事务完成时，工作负荷管理单元取消事务与EJBServer1(402)的关系。
请注意，在图4a中，提交了事务，虽然所描述的处理与提交请求(408)是一个回滚请求的情况相同。此外，虽然优选实施例使用了同步对象和after_completion方法以帮助在事务完成时钝化bean实例，但是，其他实施例也可以采用不同的方法。
处理过程在图4b中继续，该图显示了客户端的第二个事务。客户端(401)发出开始事务请求(413)，工作负荷管理单元(未显示)将此请求分配给EJBServer2(412)中的事务服务，并建立事务与此服务器进程的关系。然后，客户端向BeanCounter实例发出增量请求(414)。此请求基于建立的事务-服务器关系分配给EJBServer2(412)。容器认识到，bean实例不在易失性存储器中，从bean存储区读取并将它删除(415)。然后，将bean实例解除序列化到易失性存储器，并在其上调用ejbActivate方法(416)。在本示例中，BeanCounter实例在ejbActivate中无事可做，无法恢复其状态。然后，将增量请求(414)传递到BeanCounter实例，该请求将其状态更新到beans＝2。在增量方法返回之前，容器注意到，这是BeanCounter实例在此事务中的第一次使用，因此，它发出register_synchronization请求(417)以向事务服务注册同步对象所拥有的容器。这将确保，在事务完成处理期间用after_completion调用容器。当客户端即将完成事务时，它向发出提交请求(418)，处理过程以与为图4a所描述的从提交请求(408)开始的同样的方式继续。
如此，有状态会话bean实例在事务之间移动服务器进程，结果，每一个事务的工作负荷都得到管理。在没有本发明的情况下，创建(404)有状态会话bean实例将建立客户端-服务器关系，该关系将导致所有客户端的事务在相同服务器进程中运行。
值得注意的是，虽然上面的示例考虑了客户端启动的事务，但是，本发明还适用于容器或bean启动的事务。对于容器和bean启动的事务，所涉及的流程将类似于所描述的那些。在这样的情况下，优选实施例中的区别是，图4a和4b中的客户端(10)调用的方法将由不同的实体发出。例如，不同的EJB的容器或另一个EJB实例，可以发出开始(403、413)和提交(408、418)请求，另一个EJB实例或客户端，可以发出创建(404)和增量方法(407、414)。
此外，在单个客户端请求内启动和完成容器管理的事务。结果，作为容器管理事务的一部分被访问的有状态会话bean实例，在每个客户端请求完成时被钝化。这就可以对使用容器管理事务的所有客户端请求进行工作负荷管理。然后可以看出，在没有事务的情况下，容器还可以在非事务请求完成时钝化有状态会话bean实例，从而即使有状态会话bean实例被访问，也可以对所有请求进行工作负荷管理。
图5是根据本发明的优选实施例的图4a和4b所示的事务的略图。客户端(401)运行两个事务T1和T2，并在每一个事务的过程中，BeanCounter实例(503)被访问。T1-a(501)代表客户端(401)作为事务T1的一部分发出的请求。工作负荷管理单元(12)将所有这些请求路由到EJBServer1(402)，这些请求由T1-b(502)代表。在事务完成时，BeanCounter实例(503)的序列化表示写入(504)到bean存储区(509)并从EJBServer1(402)中的存储器删除。T2-a(506)代表客户端(401)作为事务T2的一部分发出的请求。工作负荷管理单元(12)将所有这些请求路由到EJBServer2(412)，这些请求由T2-b(507)代表。T2首次访问BeanCounter实例时，通过从bean存储区(509)读取并从中删除(508)，并在EJBServer2中的存储器中重新实例化，它在EJBServer2(402)中重新活化。结果，即使T1在不同的服务器中运行，T2也可以访问T1留下的BeanCounter实例的状态。然后，T2将bean实例的状态增加到beans＝2。
图6是根据本发明的优选实施例的在非易失性存储器上保存的能进行有状态会话bean的工作负荷管理的信息类型的说明图。显示了根据本发明可以实现的状态的序列的两个文件的内容，可恢复的路由文件，以及不可恢复的bean存储区。请注意，所显示的内容是保留的信息的细节，而不是文件的实际内容，因为保留信息的方式有许多种。此外，状态也不是详尽的，只是用来说明概念。
在图6所示的第一状态中，在Server1中有一个ID为T1的活动事务，在bean存储区有一个键为B1的钝化会话bean实例。路由表包含(601)事务id(T1)和在其中启动事务(server1)的服务器进程的表示。此信息用于维护事务-服务器关系，以便作为事务T1的一部分的所有请求都被路由到server1。bean存储区包含(602)会话bean键(B1)和其会话状态(beans＝1)。在此状态下，任何从工作组中的任何服务器进程访问bean实例的尝试都将会成功。
图6中的第二个状态是在bean实例B1在事务T1的范围内重新活化之后第一个状态的继续。路由表内容(603)未变化，但bean实例的记录已经从bean存储区删除，该bean存储区现在没有bean实例B1的记录(604)。这是因为，bean实例B1现在在server1中的易失性存储器中，因此，从server1的任何访问它的尝试都将会成功，但从工作组中的任何其他服务器进程访问都将会失败。
图6中的第三个状态是在事务T1被提交之后第二个状态的继续。路由表现在没有已完成的事务T1的记录(605)，因为事务-服务器关系已经撤消。bean存储区包含(602)会话bean键(B1)和其更新的会话状态(beans＝2)，表示bean实例在事务完成期间被钝化。
图6中的第四状态是在bean管理事务尚末完成的情况下，在钝化的bean实例B1已经被从server2访问之后第三个状态的继续。路由表包含(607)bean实例键二级B1，以及在其中bean当前是活动的服务器进程(server2)。此外，bean实例键B1包括表示bean在bean管理事务下正在被访问的标志。这将确保，下面进行的访问bean实例的尝试将被路由到server2。bean存储区没有现在处于活化状态的bean实例B1的记录(608)。此状态将一直保留，直到bean管理事务完成，此时，bean将被钝化，状态将返回到等价于图6中的第三个状态的状态，其中，路由文件不再具有bean键的记录，bean存储区包含会话bean实例。
图4所示的状态构成了优选实施例中的可能的所有状态(一个除外)。没有显示的状态是路由表不包含bean实例的键或在其中事务正在被访问并且bean存储区不包含bean实例的记录的事务的ID。此状态可以通过bean实例不存在或bean实例在超出事务的范围的一个服务器进程中处于活化状态或作为容器管理事务的一部分来实现。
因此，显示了，在本发明的优选实施例中，会话bean实例在一个事务完成时被钝化，被钝化的bean实例的序列化形式在重新活化时从bean存储区删除。结果，在重新活化之后，只有bean实例的状态的表示位于易失性存储器中的重新活化的bean实例中。这确保了，会话bean实例只能存在于一个位置，只能在完成的事务性状态从不同的服务器进程进行访问，如果在事务完成之前从失败的服务器进程在一个事务中进行访问，则无法访问。这就保证了，如果未提交的事务性的更新丢失，就无法访问有状态会话bean，结果，有状态会话bean实例中的可访问的状态始终反映所有更新。如果如此尝试访问已经无法访问的有状态会话bean实例，则请求者将收到一个相应的异常，如java.rmi.NosuchObjectException。
图7显示了根据本发明的优选实施例的当向服务器进程分配入站请求时工作负荷管理单元所遵循的逻辑。在步骤701中，进行检查，以查看请求是否为事务性的。如果请求是事务性的，则从请求中获取事务ID，并在步骤702中，将该ID与路由表中的事务ID进行比较。如果找到ID，则在步骤703中，将请求分配给路由表中指定的服务器进程。如果未找到ID，则在步骤704中，将请求分配给工作组中任何服务器进程。如果请求不是事务性的，则在步骤705中，进行检查，以查看请求是否指向在bean管理事务下正在被访问的bean实例。此信息位于bean实例的键中的标志中。如果是这种情况，则从请求获取bean实例的键，并在步骤706中，将该ID与路由表中的bean实例键进行比较。如果找到该键，则在步骤707中，将请求分配给路由表中指定的服务器进程。如果未找到该键，则在步骤704中，将请求分配给工作组中任何服务器进程。如果bean实例的键没有指出bean实例在bean管理事务下正在被访问，则不对路由表进行搜索，并在步骤704中将请求分配给任何服务器。
请注意，在bean实例的键中使用标志以指出bean实例在bean管理事务下正在被访问，是一种性能优化方法。在优选实施例中，如果bean键在bean管理事务下正在被访问，那么，它将只位于路由表中。结果，使用标志意味着，如果bean实例的键没有设置标志，则没有必要搜索路由表。如果没有使用标志，则对于指向bean实例的所有入站请求的所有bean实例键，都必须检查路由表。
值得注意的是，优选实施例使用了与CORBA兼容的OTS事务作为表示工作单元的方式。然而，本发明还可以应用于其他类型的工作单元，如不同类型的事务、会话、业务方法、客户端请求，或将一个或多个事件组合到一个单元的任何其他方式。这可以通过在所选的工作单元完成时钝化有状态会话bean实例来实现。此外，某些实施例可以使用工作单元的层次结构。例如，在其中OTS事务是所选的工作单元的优选实施例中所描述的系统中，在没有事务的情况下，也可以使用业务处理方法作为工作单元。如果客户端超出事务范围请求业务方法，并且业务方法直接或间接地访问有状态会话bean实例，那么，可以在业务方法完成时钝化有状态会话bean实例。优选情况下，这将在客户端调用的业务方法的postInvoke处理期间进行。然后，这为涉及有状态会话bean实例的客户端调用的业务方法提供工作负荷管理。
值得进一步指出的是，在优选实施例中，选择了有状态会话bean作为在存储器中维护会话状态的程序实体类型的优选实施例。然而，本发明可以应用于需要工作负荷管理支持的在存储器中维护状态的任何类型的实体，如Java bean或C++对象。
优选情况下，本发明作为与计算机系统一起使用的计算机程序产品来实现。这样的实现方式可以包括固定在诸如计算机可读的介质(例如，磁盘、CD-ROM、ROM或硬盘)之类的有形介质，或通过调制解调器或其他接口设备，通过有形的介质(包括而不仅限于，光学或模拟通信线路)，或使用无线技术(包括而不仅限于，微波、红外线或其他传输技术)可传输的到计算机系统的一系列计算机可读的指令。一系列计算机可读的指令实现了前面所描述的功能的全部或一部分。
那些精通本技术的人将理解，这样的计算机可读的指令可以以许多编程语言编写，以便与许多计算机体系结构或操作系统一起使用。此外，这样的指令可以使用任何存储技术来进行存储，当前的或未来的，包括而不仅限于，半导体、磁性、或光学，或使用任何通信技术，当前的或未来的，包括而不仅限于，光学、红外线或微波。可以预期，这样的计算机程序产品可以作为可移动介质附带打印或电子文档来进行分发，例如，包装的软件，预装到计算机系统中，例如，装到系统ROM或硬盘中，或从服务器或电子公告板通过网络(例如，因特网或万维网)进行分发。
权利要求
1.在具有非易失性存储器存储设备和至少一个服务器的能够运行服务器进程的数据处理系统中，一种对程序实体进行数据处理的方法，包括下列步骤作为第一服务器进程的一部分，通过将程序实体的实例写入到所说的存储设备上的程序实体存储区，并从所说的服务器进程中将其删除，来钝化所说的程序实体的实例；作为第二服务器进程的一部分，通过从所说的程序实体存储区读取所说的程序实体的所说的实例，并在所说的服务器进程中重新创建它，来重新活化所说的程序实体的所说的实例；以及根据工作负荷分配算法选择在其中重新活化所说的程序实体实例的服务器进程。
2.根据权利要求1所述的方法，其中，所说的钝化服务器进程代表在其中访问所说的程序实体实例的客户端执行工作单元，所说的钝化步骤在完成所说的工作单元时钝化所说的程序实体实例。
3.根据权利要求2所述的方法，其特征在于，所说的工作单元包括事务。
4.根据权利要求2所述的方法，其特征在于，所说的工作单元包括业务方法。
5.根据前面的任何一个权利要求所述的方法，其特征在于，所说的程序实体包括有状态会话bean。
6.根据权利要求2到4中的任何一个权利要求所述的方法，其特征在于，所说的重新活化步骤从所说的程序实体存储区读取所说的程序实体的所说的实例并将其删除，从而确保，如果所说的程序实体实例在所说的工作单元下重新活化，则在直到所说的工作单元完成之前无法从所说的工作单元外面重新访问它。
7.根据权利要求1到4中的任何一个权利要求所述的方法，进一步包括下列步骤在所说的存储设备上维护一个路由表中程序实体实例位置信息，其特征在于，所说的路由表用于定位许多程序实体实例，所说的信息表示程序实体实例在所说的许多服务器进程中的某一个中是处于活化状态，还是在所说的程序实体存储区处于钝化状态。
8.根据权利要求7所述的方法，进一步包括下列步骤将一个键与所说的许多程序实体实例中的至少一个关联，用于将所说的至少一个程序实体实例标识为请求的目标，其中，所说的键包括一个标志，表示所说的至少一个程序实体实例的位置信息在所说的路由表中存在。
9.一种存储在计算机可读的存储介质上的计算机程序产品，用于具有非易失性存储器存储设备和至少一个服务器的能够运行服务器进程的数据处理系统中，所说的产品包括指令，当执行这些指令时，导致所说的系统通过执行下列步骤来处理程序实体作为第一服务器进程的一部分，通过将程序实体的实例写入到所说的存储设备上的程序实体存储区，并从所说的服务器进程中将其删除，来钝化所说的程序实体的实例；作为第二服务器进程的一部分，通过从所说的程序实体存储区读取所说的程序实体的所说的实例，并在所说的服务器进程中重新创建它，来重新活化所说的程序实体的所说的实例；以及根据工作负荷分配算法选择在其中重新活化所说的程序实体实例的服务器进程。
10.根据权利要求9所述的计算机程序产品，其中，所说的钝化服务器进程代表在其中访问所说的程序实体实例的客户端执行工作单元，所说的钝化步骤在完成所说的工作单元时钝化所说的程序实体实例。
11.根据权利要求10所述的计算机程序产品，其特征在于，所说的工作单元包括事务。
12.根据权利要求10所述的计算机程序产品，其特征在于，所说的工作单元包括业务方法。
13.根据权利要求9到12中的任何一个权利要求所述的计算机程序产品，其特征在于，所说的程序实体包括有状态会话bean。
14.根据权利要求10到12中的任何一个权利要求所述的计算机程序产品，其特征在于，所说的重新活化步骤从所说的程序实体存储区读取所说的程序实体的所说的实例并将其删除，从而确保，如果所说的程序实体实例在所说的工作单元下重新活化，则在直到所说的工作单元完成之前无法从所说的工作单元外面重新访问它。
15.根据权利要求9到12中的任何一个权利要求所述的计算机程序产品，进一步包括下列步骤在所说的存储设备上一个路由表中维护程序实体实例位置信息，其特征在于，所说的路由表用于定位许多程序实体实例，所说的信息表示程序实体实例在所说的许多服务器进程中的某一个中是处于活化状态，还是在所说的程序实体存储区处于钝化状态。
16.根据权利要求15所述的计算机程序产品，进一步包括下列步骤将一个键与所说的许多程序实体实例中的至少一个关联，用于将所说的至少一个程序实体实例标识为请求的目标，其特征在于，所说的键包括一个标志，表示所说的至少一个程序实体实例的位置信息在路由表中存在。
17.一种数据处理系统，包括至少一个服务器；许多能够在所说的至少一个服务器上运行的服务器进程，其中每个服务器进程都支持程序实体；以及每一个服务器进程都可以访问到的非易失性存储器存储设备；其中，每一个服务器进程都包括用于通过将所说的程序实体的实例写入到所说的存储设备上的程序实体存储区来钝化所说的程序实体的实例的装置；用于通过从所说的程序实体存储区读取所说的程序实体的实例，并使用它来重新创建所说的程序实体实例，来重新活化所说的程序实体的实例的装置；所说的用于重新活化的装置能够重新活化被不同的服务器进程的钝化装置钝化的程序实体实例；以及用于根据工作负荷分配算法选择在其中重新活化所说的特定程序实体实例的服务器进程的装置。
18.根据权利要求17所述的数据处理系统，所说的许多服务器进程中的每一个都进一步包括用于代表在其中访问所说的程序实体的第一个实例的客户端执行工作单元的装置；其中，所说的用于钝化所说的程序实体实例的装置在所说的工作单元完成时钝化所说的第一个程序实体实例。
19.根据权利要求18所述的数据处理系统，其特征在于，所说的工作单元包括事务。
20.根据权利要求18所述的数据处理系统，其特征在于，所说的工作单元包括业务方法。
21.根据权利要求17到20中的任何一个权利要求所述的数据处理系统，其特征在于，所说的程序实体包括有状态会话bean。
22.根据权利要求18到20中的任何一个权利要求所述的数据处理系统，其特征在于，所说的重新活化装置从所说的程序实体存储区读取所说的程序实体的实例并将其删除，从而确保，如果所说的重新活化装置在所说的工作单元中重新活化所说的第一个程序实体实例，则在直到所说的工作单元完成之前无法从所说的工作单元外面重新访问所说的第一个程序实体实例。
23.根据权利要求17到20中的任何一个权利要求所述的数据处理系统，所说的许多服务器进程中的每一个都进一步包括用于在所说的存储设备上维护一个路由表中程序实体实例位置信息的装置，其中，所说的路由表用于定位许多程序实体实例，所说的信息表示程序实体在所说的许多服务器进程中的某一个中是处于活化状态，还是在所说的程序实体存储区处于钝化状态。
24.根据权利要求23所述的数据处理系统，每一个服务器进程都进一步包括用于将一个键与一个程序实体实例关联的装置，用于将所说的程序实体实例标识为请求的目标，其中，所说的键包括一个标志，表示所说的至少一个程序实体实例的位置信息在路由表中存在。
全文摘要
在包括许多服务器进程的工作负荷管理系统中，每一个服务器进程都能够支持一个给定的程序实体，如，Enterprise JavaBeans
文档编号G06F9/46GK1516831SQ02807390
公开日2004年7月28日 申请日期2002年3月7日 优先权日2001年3月29日
发明者安德鲁·S·克莱门特, 安·E.·多尔顿, 巴里·迪克恩森, 托马斯·J.·弗路恩德, 乔纳森·P.·H.劳伦斯, 伊恩·J.·米切尔, 格林·诺明顿, 史蒂文·普威尔, 安索尼·斯多瑞, J. 弗路恩德, P. H.劳伦斯, 多尔顿, 斯多瑞, 普威尔, J. 米切尔, 安德鲁 S 克莱门特, 诺明顿, 迪克恩森 申请人:国际商业机器公司