Browse Prior Art Database

Efficient Management of Database Connections for the J2EE* Applications

IP.com Disclosure Number: IPCOM000028872D
Original Publication Date: 2004-Jun-04
Included in the Prior Art Database: 2004-Jun-04
Document File: 3 page(s) / 101K

Publishing Venue

IBM

Abstract

The invention enables more efficient management of database connections in J2EE* by enabling applications to provide notification when the connections are no longer being used.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 42% of the total text.

Page 1 of 3

Efficient Management of Database Connections for the J 2EE* Applications

The invention enables more efficient management of database connections in J2EE* by enabling applications to provide notification when the connections are no longer being used.

    In the J2EE Connector Architecture (JCA), J2EE applications use a connection object provided by the resource adapter to access the database or enterprise information system (EIS). This connection can be an object that implements the javax.cci.resource.Connection or java.sql.Connection interface. When the application finishes using a connection object, it closes the connection object acquired from the resource adapter. Because of the connection pooling feature that is defined in the J2EE Connector Architecture, the physical connection to the database or EIS is still cached in the connection pool for performance purposes. Today, when the application is either done with this connection or will not access the database for a long period of time, there is no way for the application to notify the application server to remove the physical connection from the connection pool. The physical connection will stay open in the connection pool until one of the following situations happens:

If any error indicating that a physical connection is unusable, the connection will be

purged from the pool. One example is after a database has been restarted, the connections acquired before the database restart are not valid any more. The connection has been inactive for a certain amount of time (quite large). In this

case, the physical connection will be closed. When the connection pool is full, and a new physical connection is acquired, one of

the existing physical connections in the connection pool will be claimed as a victim based on the victim claim policy. This is all done while the new request is waiting.

    However, knowing that we can immediately close a physical connection after it is used can immediately release the resources in both the application server and database. This is critical to those databases that have limited resource. This could be helpful if the application knows that it won't use this connection again in a certain period of time, or when a stale condition occurs where this connection should be released right away. However, this usage pattern information -- that the connection won't be used for a certain period of time, is only known by the application. Therefore, letting applications notify the application server is necessary in order to more efficiently release the resource.

    Our solution is to allow the application to send a connection release message to the application server, and then the physical connection can be closed and removed from the connection pool. In order to let applications notify the application server, we propose to create a ConnectionNotifier interface. This interface will have a method called releaseConnection(Object connection). Applications can call this releaseConn...