Disassociating and freeing managed connections based on usage patterns

A method, system and computer program product for disassociating and freeing managed connection objects. Managed connections are dissociated from their connection handles based on their usage patterns, determined by various connection parameters, which more effectively reduces the idle time of the managed connections. The managed connections whose cost of disassociating and reassociating is less than the cost of keeping the managed connections idle are targeted and released to the free pool of managed connections via the dissociation from its connection handles.

TECHNICAL FIELD

The present invention relates to the J2EE Connector Architecture (JCA), and more particularly to disassociating and freeing managed connection objects to a pool of available managed connection objects based on usage patterns.

BACKGROUND

The Java 2 Platform, Enterprise Edition (J2EE) is a software standard for developing multitier enterprise applications. The J2EE architecture has a client tier, middle tier, and back-end tier. The client tier supports a variety of client types, and the middle tier supports client services and business logic through web and Enterprise Java Beans (EJB) containers in the middle tier. The back-end tier includes the Enterprise Information Systems (EIS) in the EIS tier and many standard Application Programming Interfaces (APIs) for accessing databases. An Enterprise Information System is generally any kind of computing system that offers high quality of service, deals with large volumes of data and capable of supporting some large organization (“an enterprise”). One of skill in the art can accordingly alter the objects and components resident on the several tiers. “Containers” are standardized runtime environments that provide services to components on the platform. All containers provide runtime support for responding to client requests and returning results to clients. The containers also provide APIs to support user session management.

Resident within the J2EE architecture is a “resource adapter” that plays a central role in the integration and connectivity between an EIS and an application server (software framework dedicated to the efficient execution of procedures for supporting the construction of applications) and serves as the point of contact between application components, application servers and enterprise information systems. A resource adapter and other components, must communicate with one another based on a standard referred to as the J2EE Connector Architecture (JCA). To enable seamless integration with an application server, the resource adapter abides by system-level “contracts” defined by the JCA. These contracts exist between the application server and the EIS, and are implemented through the resource adapter. The contracts specify how a system external to the J2EE platform integrates with it by supporting basic functions handled by the J2EE container. There are three major contracts: the “connection management contract” which allows applications to connect to an EIS, and enables the application server to utilize pooling; the “transaction management contract” which allows an application server to manage and perform transactional access across one to many EIS resource managers; and the “security contract” which provides support for secure access to the EIS.

On a J2EE platform, a “ManagedConnection” interface provides an application-level connection handle from the EIS to the resource adapter's ManagedConnection instance. The ManagedConnection instance represents a physical connection to the underlying EIS. A connection handle to the ManagedConnection instance is created for the application that requests a physical connection represented by the ManagedConnection instance. This connection handle is used by the application code to refer to the underlying physical connection. The ManagedConnection instance is associated with the connection handle until the connection handle is closed and the associated transaction (e.g., loading personalized data from a database) is terminated.

In certain situations, the transaction may take a considerable amount of time to complete. In such cases, the ManagedConnection object is idle without being actively engaged in any sort of work.

Attempts have been made to reduce or eliminate these idle times by disassociating the ManagedConnection object from its connection handles when the processing is completed regardless of whether the transaction is completed or not. For example, when a portal application acquires a connection to load all personalization data from a database, the ManagedConnection object would be disassociated from its connection handles for this connection when the processing is completed. However, the time it takes to process the data may be significantly greater than the time it takes to load the data thereby causing the ManagedConnection object to be idle for a significant period of time.

As a result, there are cases where the connection resources, such as the ManagedConnection object, are being underutilized.

BRIEF SUMMARY

In one embodiment of the present invention, a method for disassociating and freeing managed connection objects comprising determining an amount of time a managed connection has been idled. The method further comprises determining an average amount of time that the managed connection is in an idle state. Additionally, the method comprises computing a standard deviation of a number of accesses to a physical connection represented by the managed connection over a time the managed connection has been idled. In addition, the method comprises disassociating, by a connection manager of an application server whose instructions are executed by a processor, the managed connection from a connection handle in response to the amount of time the managed connection has been idled being less than or greater than the standard deviation from the average time the managed connection is in the idle state and in response to the amount of time the managed connection has been idled being greater than the average time the managed connection is in the idle state, where the connection handle is used by an application to refer to the physical connection represented by the managed connection.

DETAILED DESCRIPTION

The present invention comprises a method, system and computer program product for disassociating and freeing managed connection objects. In one embodiment of the present invention, managed connections are dissociated from their connection handles based on their usage patterns, determined by various connection parameters, which more effectively reduces the idle time of the managed connections. The managed connections whose cost of disassociating and reassociating is less than the cost of keeping the managed connections idle are targeted and released to the free pool of managed connections via the dissociation from its connection handles.

Referring now to the Figures in detail,FIG. 1illustrates an embodiment of a hardware configuration of a computer system100which is representative of a hardware environment for practicing the present invention. Referring toFIG. 1, computer system100may have a processor101coupled to various other components by system bus102. An operating system103may run on processor101and provide control and coordinate the functions of the various components ofFIG. 1. An application104in accordance with the principles of the present invention may run in conjunction with operating system103and provide calls to operating system103where the calls implement the various functions or services to be performed by application104. Application104may include, for example, a user application that requests a physical connection represented by the managed connection object (e.g., ManagedConnection instance defined in the J2EE platform). Application104may also include the software components used for disassociating and freeing managed connection objects (“managed connects”) based on their usage patterns, as discussed further below in association withFIGS. 2,3A-3C and4.

Referring again toFIG. 1, read-only memory (“ROM”)105may be coupled to system bus102and include a basic input/output system (“BIOS”) that controls certain basic functions of computer device100. Random access memory (“RAM”)106and disk adapter107may also be coupled to system bus102. It should be noted that software components including operating system103and application104may be loaded into RAM106, which may be computer system's100main memory for execution. Disk adapter107may be an integrated drive electronics (“IDE”) adapter that communicates with a disk unit108, e.g., disk drive. It is noted that the applications of application104as discussed further below in association withFIGS. 2,3A-3C and4, may reside in disk unit108or in application104.

Computer system100may further include a communications adapter109coupled to bus102. Communications adapter109may interconnect bus102with an outside network (not shown) thereby allowing computer system100to communicate with other similar devices.

I/O devices may also be connected to computer system100via a user interface adapter110and a display adapter111. Keyboard112, mouse113and speaker114may all be interconnected to bus102through user interface adapter110. Data may be inputted to computer system100through any of these devices. A display monitor115may be connected to system bus102by display adapter111. In this manner, a user is capable of inputting to computer system100through keyboard112or mouse113and receiving output from computer system100via display115or speaker114.

Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the present invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to product a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the function/acts specified in the flowchart and/or block diagram block or blocks.

As stated in the Background section, there are cases where the connection resources, such as the managed connection object (e.g., ManagedConnection instance defined on a J2EE platform), are being underutilized. For example, the managed connection object is being idled without being actively engaged in any sort of work.

The principles of the present invention provide a technique for dissociating and freeing the managed connections from their connection handles based on their usage patterns thereby more effectively reducing or eliminating these idle times as discussed below in connection withFIGS. 2,3A-3C and4.FIG. 2is a diagram of the software components used in the technique for disassociating and freeing managed connection objects (“managed connections”) based on their usage patterns.FIGS. 3A-3Care a flowchart of a method for disassociating and freeing managed connection objects based on their usage patterns.FIG. 4is a graph illustrating an example of the normal distribution of the number of accesses to the physical connection represented by the managed connection over the time that the managed connection has been idled.

Referring toFIG. 2, as stated above,FIG. 2is a diagram of the software components used in the technique for disassociating and freeing managed connection objects based on their usage patterns in accordance with an embodiment of the present invention. In one embodiment, these software components may reside in application104(FIG. 1).

The software components include an application server201interacting with a resource adapter202. In one embodiment, application server201is a software framework dedicated to the efficient execution of procedures for supporting the construction of applications. In one embodiment, resource adapter202plays a central role in the integration and connectivity between application server201and an Enterprise Information System (EIS) (not shown).

Resource adapter202includes a managed connection objection “managed connection”203within the J2EE architecture that represents a physical connection to the underlying EIS. Resource adapter202further includes one or more connection handles, such as connection handle204, which is created for a user application that requests a physical connection represented by managed connection203.

Application server201includes a connection manager205configured to disassociate managed connection203from its connection handles204based on the usage of managed connection203and freeing the disassociated managed connection203to a pool of available managed connections203(“connection pool”). Once in the pool of managed connections203, the disassociated managed connection203can be reused to represent another physical connection to the underlying EIS. In this manner, managed connection203may be used to represent another physical connection to the underlying EIS rather than being idled.

The process in connection manager205disassociating managed connection203from its connection handles204thereby reducing or eliminating its idle time is discussed below in connection withFIGS. 3A-3C.FIGS. 3A-3Care a flowchart of a method300for disassociating and freeing managed connection objects (“managed connections”) based on their usage patterns in accordance with an embodiment of the present. While the following discusses calculating various metrics (e.g., meanIdleTime, meanUseTime, dissociate time, reassociate time) per managed connection203, these metrics may be calculated per connection pool.

Referring toFIG. 3A, in conjunction withFIGS. 1-2, in step301, connection manager205determines the amount of time managed connection203has currently been idled.

In step302, connection manager205determines the average amount of time that managed connection203is in the idle state.

In step303, connection manager205computes the standard deviation from the normal distribution of accesses to a physical connection represented by managed connection203over the time managed connection203has been idled as illustrated inFIG. 4. Referring toFIG. 4,FIG. 4is a graph400of the number of accesses to a physical connection (identified by401) versus the time managed connection203has been idled (“idle time”402). Graph400also illustrates the mean or average (identified by “mean”403) of the number of accesses to a physical connection represented by managed connection203over the time managed connection203has been idled. Furthermore, graph400illustrates computing the standard deviation (identified by “SD”) from the mean value403. In particular, graph400shows the locations404,405where the number of connection accesses to a physical connection is one standard deviation from mean403. The information from graph400will be used in determining whether to disassociate managed connection203from its connection handles204as discussed below in connection with the remaining steps of method300.

Returning toFIG. 3A, in conjunction withFIGS. 1,2and4, in step304, connection manager205determines if the amount of time that managed connection203has been idled is less than or greater than one standard deviation (points404,405in graph400) from the average time (point403in graph400) managed connection203is in the idle state.

If the amount of time that managed connection203has been idled is less than or greater than one standard deviation (points404,405in graph400) from the average time (point403in graph400) managed connection203is in the idle state, then, in step305, connection manager205computes the parameter (idleThreshold) which estimates the cost of disassociating managed connection203from its connection handles204and reassociating it with another physical connection to the underlying EIS. By quantifying the cost of disassociating and reassociating managed connections203, those managed connections203whose cost of disassociating and reassociating is less than the cost of keeping the managed connection203idle should be targeted and released to the free pool via dissociation from its connection handles204as discussed further below. In one embodiment, the parameter idleThreshold is equation to the following equation:
idleThreshold=2*(average(dissociate time+reassociate time)),  (EQ1)

where the average dissociate time is the average time it takes to dissociate a managed connection203from its connection handles204and the average reassociate time is the average time it takes to reassociate the freed managed connection203to another physical connection to the underlying EIS.

In step306, connection manager205computes the parameter (meanUseTime) which is the average amount of time that managed connection203is in use (engaged in work).

In step307, connection manager205computes the parameter (bufferTime) which corresponds to an amount of time that takes into consideration the variations in time in disassociating and reassociating managed connection203. In one embodiment, the parameter bufferTime is user selected.

where meanIdleTime corresponds to the average amount of time that managed connection203is in the idle state as discussed above in step302, currentIdleTime corresponds to the amount of time managed connection203has been currently idled as discussed above in step301.

Referring toFIG. 3C, if equation EQ2 is satisfied, then, in step309, connection manager205disassociates managed connection203from its connection handles204and releases managed connection203to a free pool (i.e., a pool of managed connections203available to be used to represent another physical connection to the underlying EIS).

Alternatively, if equation EQ2 is not satisfied, then, in step310, connection manager205determines if the amount of time that managed connection203has been idled exceeds the average time that connection manager203is in the idle state which is represented by the following equation:
currentIdleTime>meanIdleTime  (EQ3)

If equation EQ3 is satisfied, then, in step309, connection manager205disassociates managed connection203from its connection handles204and releases managed connection203to a free pool (i.e., a pool of managed connections203available to be used to represent another physical connection to the underlying EIS).

Referring to step304ofFIG. 3A, if the amount of time that managed connection203has been idled is not less than or greater than one standard deviation from the average time managed connection203is in the idle state, then, in step311ofFIG. 3C, connection manager205determines if the following equation is satisfied:
((2*idleThreshold)+meanUseTime+bufferTime)<(1*n*SD),  (EQ4)

where n is an integer that is initially set to equal 1.

If equation EQ4 is satisfied, then, in step312, connection manager205determines if the following equation is satisfied:
|(meanIdleTime−currentIdleTime)|>((2*idleThreshold)+meanUseTime+bufferTime)  (EQ5)

If equation EQ5 is satisfied, then, in step309, connection manager205disassociates managed connection203from its connection handles204and releases managed connection203to a free pool (i.e., a pool of managed connections203available to be used to represent another physical connection to the underlying EIS).

If, however, EQ5 is not satisfied, then, in step313, connection manager205reduces the previous value of n by 0.1 and determines if equation EQ4 is satisfied in step311.

Referring to step311, if equation EQ4 is not satisfied, then method300is terminated in step314.

In this manner, managed connections203are dissociated and released to a pool of managed connections203based on their usage patterns, determined by various connection parameters discussed above, which more effectively reduces the idle time of managed connections203. Managed connections203whose cost of disassociating and reassociating is less than the cost of keeping the managed connection203idle are targeted and released to the free pool via dissociation from its connection handles204.

In some implementations, method300may include other and/or additional steps that, for clarity, are not depicted. Further, in some implementations, method300may be executed in a different order presented and that the order presented in the discussion ofFIGS. 3A-3Cis illustrative. Additionally, in some implementations, certain steps in method300may be executed in a substantially simultaneous manner or may be omitted.

Although the method, system and computer program product are described in connection with several embodiments, it is not intended to be limited to the specific forms set forth herein, but on the contrary, it is intended to cover such alternatives, modifications and equivalents, as can be reasonably included within the spirit and scope of the invention as defined by the appended claims.