Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

A Method for Coordinating SQL Cursor States in a Client/Server Environment When Using Nested Savepoints on a Relational Database

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

Publishing Venue

IBM

Abstract

Disclosed is an algorithm to efficiently communicate to a database client the different cursor states that are possible as the result of processing a rollback to savepoint statement on a relational database system. When a cursor is opened by an application, information about the cursor, including the fact that it is opened, is stored at both the client and server layers in a relational database. With the introduction of nested application savepoints, a user is now able define each savepoint as having a different behaviour towards cursors in that a savepoint can be defined to either close or retain cursors within its scope should it be rolled back. This disclosure shows a way to succinctly communicate information from the server to the client about the final state of any cursors active within the scope of a savepoint when that savepoint is rolled back. This algorithm is implemented by associating a unique value with each new savepoint when it is started and then associating this value in the database client with any cursor opened within the same savepoint. This value, also known as a savepoint ID, is returned to the client as part of the response to the OPEN request for the cursor and is stored with the client cursor information. If a rollback to savepoint request is processed by the database server, the response to that request would contain a savepoint ID indicating which, if any cursors, need to be closed at the client. The client would close all cursors with an associated savepoint ID greater than or equal to the one returned. The algorithm can be implemented in the following manner: for each new unit of work (UOW), reset the UOW unique counter at the server to 0

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

Page 1 of 2

  A Method for Coordinating SQL Cursor States in a Client/Server Environment When Using Nested Savepoints on a Relational Database

  Disclosed is an algorithm to efficiently communicate to a database client the different cursor states that are possible as the result of processing a rollback to savepoint statement on a relational database system. When a cursor is opened by an application, information about the cursor, including the fact that it is opened, is stored at both the client and server layers in a relational database. With the introduction of nested application savepoints, a user is now able define each savepoint as having a different behaviour towards cursors in that a savepoint can be defined to either close or retain cursors within its scope should it be rolled back. This disclosure shows a way to succinctly communicate information from the server to the client about the final state of any cursors active within the scope of a savepoint when that savepoint is rolled back.

This algorithm is implemented by associating a unique value with each new savepoint when it is started and then associating this value in the database client with any cursor opened within the same savepoint. This value, also known as a savepoint ID, is returned to the client as part of the response to the OPEN request for the cursor and is stored with the client cursor information. If a rollback to savepoint request is processed by the database server, the response to that request would contain a savepoint ID indicating which, if any cursors, need to be closed at the client. The client would close all cursors with an associated savepoint ID greater than or equal to the one returned.

The algorithm can be implemented in the following manner:

for each new unit of work (UOW), reset the UOW unique counter at the server to 0

for each new savepoint, increment the UOW unique counter at the server and store as that

savepoint's ID When an OPEN cursor request is received, the current savepoint ID number is sent back in the

response to the OPEN this value is stored in the client cursor information the value sent back is 0 if no active savepoint the current savepoint ID At rollback to savepoint, if the savepoint being rolled back has the close cursor attribute, return

the value of that savepoint's ID in the response to the rollback to savepoint request At rollback to savepoint, if the savepoin...