Browse Prior Art Database

Supporting Session Reuse Via Client Session Replay

IP.com Disclosure Number: IPCOM000014309D
Original Publication Date: 2000-Dec-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 2 page(s) / 55K

Publishing Venue

IBM

Abstract

This disclosure describes a method to provide support for multiple logical sessions over the same physical connection to a relational database system through the introduction of session replay logic into the client side of a database connection. Session replay logic requires that the essential elements of each session, such as the values of those SQL special registers that can be updated by an application and the current authorization ID, be stored at the client and then replayed back to the database when the session is to be restarted. This session replay logic can be implemented either in the client code provided by the database product or within an application itself. The introduction of logical sessions allows for the preservation of distinct environments and authorization IDs between different logical users of the same physical connection. When used by an application server within a connection pooling environment (i.e. where number of application connections active at one time exceeds the number of active database connections), these logical sessions can be quickly stopped and restarted as desired in order to respond to requests from different applications without the need to reset a physical database connection. A session is considered to be the equivalent of one, or more, unit of work on the relational database in which one or more requests from the same application can be processed in a consistent environment and authorization ID. The rest of this disclosure describes how this method can be implemented in the context of an application server connecting to a relational database system: If the ability to reset SQL special registers to their original default values at connection start time is not provided by the database, then when a connection is first established by the application server to the database, the initial values of all updatable SQL special registers for the new connection should be stored at the client. These values can be acquired by having them returned by the database when the connection is established, if this function is available, or the database can be queried by the client, using standard SQL statements, to get the register values.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

Supporting Session Reuse Via Client Session Replay

This disclosure describes a method to provide support for multiple logical sessions over the same physical connection to a relational database system through the introduction of session replay logic into the client side of a database connection. Session replay logic requires that the essential elements of each session, such as the values of those SQL special registers that can be updated by an application and the current authorization ID, be stored at the client and then replayed back to the database when the session is to be restarted. This session replay logic can be implemented either in the client code provided by the database product or within an application itself.

The introduction of logical sessions allows for the preservation of distinct environments and authorization IDs between different logical users of the same physical connection. When used by an application server within a connection pooling environment (i.e. where number of application connections active at one time exceeds the number of active database connections), these logical sessions can be quickly stopped and restarted as desired in order to respond to requests from different applications without the need to reset a physical database connection. A session is considered to be the equivalent of one, or more, unit of work on the relational database in which one or more requests from the same application can be processed in a consistent environment and authorization ID.

The rest of this disclosure describes how this method can be implemented in the context of an application server connecting to a relational database system:

If the ability to reset SQL special registers to their original default values at connection start time is not provided by the database, then when a connection is first established by the application server to the database, the initial values of all updatable SQL special registers for the new connection should be stored at the client. These values can be acquired by having them returned by the database when the connection is established, if this function is available, or the database can be queried by the client, using standard SQL statements, to get the register values.

When a session is started, the application server indicates if the session should be remembered or not and what authorization ID is to be used for the session. The values of all updatable SQL special registers are reset to the initial connection values by either replaying the stored values in a series of standard SQL statements or by requesting that the database do this based on bulk input...