RECOVERING STATEFUL READ-ONLY DATABASE SESSIONS

• US 20130066837A1
• Filed: 09/09/2011
• Published: 03/14/2013
• Est. Priority Date: 09/09/2011
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Colrain, Carol L., Zhou, Tong, Surber, Douglas N., Neel, Kevin S., Roesch, Stefan Heinrich, Ikeda, Nancy R.
• Granted Patent: US 8,549,154 B2
• Time in Patent Office: Days
• US Class Current: 707/674
• CPC Class Codes: G06F 16/21 Design, administration or maintenance of databases
• CPC Class Codes: G06F 16/2365 Ensuring data consistency and integrity

Abstract

A process, apparatus, and computer-readable medium are provided for rebuilding a database session when a previous database session becomes unavailable and the commands previously sent for execution on the previous database session satisfy certain criteria. The process includes determining whether or not a set of commands sent by a client for execution on the previous database session is acceptable to replay based at least in part on whether or not the set of commands satisfies one or more criteria. The process further includes determining that the previous database session is unavailable. In response to determining that the previous database session is unavailable, if the set of commands is acceptable for replay, the set of commands is sent for execution on a new database session to rebuild the state on the new database session. The process masks the outage from the application.

Claims

1. A process comprising:

determining whether or not a set of commands sent by a client for execution on a first database session is acceptable to replay based at least in part on whether or not the set of commands satisfies one or more criteria;

determining that the first database session is not available;

in response to determining that the first database session is not available, if the set of commands is acceptable for replay, sending the set of commands for execution on a second database session to rebuild a state on the second database session, wherein the state was exposed to the client on the first database session;

wherein the process is performed by one or more computing devices.

2. The process of claim 1, further comprising:

receiving, on the first database session, a first set of results in response to the set of commands sent on the first database instance;

receiving, on the second database session, a second set of results in response to the set of commands sent on the second database session;

determining whether the first set of results matches the second set of results;

in response to determining that the first set of results matches the second set of results, determining that sending the set of commands for execution on the second database session rebuilt the state on the second session.

3. The process of claim 2, further comprising:

receiving a first set of one or more responses on the first database session, and extracting the first set of results that were exposed to the client from the first set of responses;

receiving a second set of one or more responses on the second database session, and extracting the second set of results that would be exposed to the client from the second set of responses;

wherein the first set of results do not include a first subset of results that were not exposed to the client, and wherein the second set of results do not include a second subset of results that were not exposed to the client.

4. The process of claim 1, further comprising:

determining a first value using a procedure by inputting, to the procedure, a first set of results received on the first database session in response to the set of commands sent on the first database session;

determining a second value using the procedure by inputting, to the procedure, a second set of results received on the second database session in response to the set of commands sent on the second database session;

determining whether the first value matches the second value;

in response to determining that the first value matches the second value, determining that sending the set of commands for execution on the second database session rebuilt the state on the second session.

5. The process of claim 4, wherein the procedure is a checksum procedure, and wherein the value is a checksum value, and wherein the checksum value is a fixed size regardless of a size of the first set of results and a size of the second set of results.

6. The process of claim 1, wherein the set of commands is a first set of commands, and wherein the state is a first state, the process further comprising:

determining that a second set of commands sent by a client for execution on a third database session is not acceptable to replay based at least in part on whether or not the set of commands satisfies one or more criteria;

in response to determining that the second set of commands is not acceptable for replay, disabling replay of the second set of commands;

determining that the third database session is not available;

in response to determining that the third database session is not available, allowing the third database session to fail without rebuilding to rebuild a second state on any other database session, wherein the second state was exposed to the client on the third database session.

7. The process of claim 1, wherein determining whether or not the set of commands is acceptable to replay is performed prior to determining that the first database session is not available, the process further comprising, in response to determining that the set of commands is not acceptable to replay, setting a flag that indicates disqualifying criteria was detected in the set of commands.

8. The process of claim 7, further comprising, in response to determining that the set of commands is not acceptable for replay, disabling replay and purging the set of commands.

9. The process of claim 1, wherein one or more commands of the set of commands are sent on the second database session with one or more identifiers of one or more states of the database in which the one or more commands were previously executed on the first database session, and wherein one or more other commands of the set of commands are sent on the second database session for re-execution against current states of the database.

10. The process of claim 1, further comprising:

receiving, on an application programming interface, marked boundaries that delimit requests on a same session from each other where a request is marked with a begin marker at the beginning an end marker at the end in this way allowing a client driver and server to know where requests begin and end.

11. The process of claim 1, further comprising, after sending the set of commands for execution on the second database session, sending one or more other commands for execution on the second database session, wherein at least one of the one or more other commands depend on the state that was exposed to the client on the first database session.

23. The method of claim 10, wherein the set of commands is a first set of commands, further comprising, for a second request comprising a second set of commands, determining whether or not the second set of commands, separately from the first set of commands, is acceptable to replay based at least in part on whether or not the second set of commands satisfies one or more criteria.

25. The process of claim 1, further comprising:

indicating, to a server, marked boundaries that delimit a beginning and an ending of a request on a dedicated connection.

26. The process of claim 1, further comprising:

at a connection pool that manages server connections for a client driver used by two or more client sessions, automatically marking boundaries that delimit a beginning and an ending of a request, wherein automatically marking the boundaries comprises;

marking the beginning of the request when a connection is checked out from the pool, and

marking the ending of the request when a connection is checked back into the pool.

27. The process of claim 1, further comprising:

at a connection pool that manages server connections within an application, automatically marking boundaries that delimit a beginning and an ending of a request, wherein automatically marking the boundaries comprises;

marking the beginning of the request when a connection is checked out from the pool, and

marking the ending of the request when a connection is checked back into the pool.

31. The process of claim 1, further comprising, in response to determining that the state has been successfully rebuilt on the second database session, causing operation of an application that originated the set of commands to continue without experiencing an outage.

12. One or more non-transitory storage media storing instructions which, when executed by one or more computing devices, cause performance of:

determining whether or not each command sent by a client for execution on a first database session is acceptable to replay based at least in part on whether or not the set of commands satisfies one or more criteria;

determining that the first database session is not available;

in response to determining that the first database session is not available, if replay is enabled and time limits have not expired and it is safe to replay, sending the set of commands for execution on a second database session to rebuild a state on the second database session, wherein the state was exposed to the client on the first database session.

13. The one or more non-transitory storage media of claim 12, wherein the instructions, when executed, further cause:

receiving, on the first database session, a first set of results in response to the set of commands sent on the first database instance;

receiving, on the second database session, a second set of results in response to the set of commands sent on the second database session;

determining whether the first set of results matches the second set of results;

in response to determining that the first set of results matches the second set of results, determining that sending the set of commands for execution on the second database session rebuilt the state on the second session.

14. The one or more non-transitory storage media of claim 13, wherein the instructions, when executed, further cause:

receiving a first set of one or more responses on the first database session, and extracting the first set of results that were exposed to the client from the first set of responses;

receiving a second set of one or more responses on the second database session, and extracting the second set of results that would be exposed to the client from the second set of responses;

wherein the first set of results do not include a first subset of results that were not exposed to the client, and wherein the second set of results do not include a second subset of results that were not exposed to the client.

15. The one or more non-transitory storage media of claim 12, wherein the instructions, when executed, further cause:

determining a first value using a procedure by inputting, to the procedure, a first set of results received on the first database session in response to the set of commands sent on the first database session;

determining a second value using the procedure by inputting, to the procedure, a second set of results received on the second database session in response to the set of commands sent on the second database session;

determining whether the first value matches the second value;

in response to determining that the first value matches the second value, determining that sending the set of commands for execution on the second database session rebuilt the state on the client again correctly.

16. The one or more non-transitory storage media of claim 15, wherein the procedure is a checksum procedure, and wherein the value is a checksum value, and wherein the checksum value is a fixed size regardless of a size of the first set of results and a size of the second set of results wherein the checksum is applied per call, and is accumulated as the seed for the next call, so that the client state is known to be the same.

17. The one or more non-transitory storage media of claim 12, wherein the set of commands is a first set of commands, and wherein the state is a first state, and wherein the instructions, when executed, further cause:

determining that a second set of commands sent by a client for execution on a third database session is not acceptable to replay based at least in part on whether or not the set of commands satisfies one or more criteria;

in response to determining that the second set of commands is not acceptable for replay, disabling replay of the second set of commands;

determining that the third database session is not available;

in response to determining that the third database session is not available, allowing the third database session to fail without rebuilding to rebuild a second state on any other database session, wherein the second state was exposed to the client on the third database session.

18. The one or more non-transitory storage media of claim 12, wherein determining whether or not the set of commands is acceptable to replay is performed prior to determining that the first database session is not available, and wherein the instructions, when executed, further cause:

in response to determining that the set of commands is not acceptable to replay, setting a flag that indicates disqualifying criteria was detected in the set of commands.

19. The one or more non-transitory storage media of claim 18, wherein the instructions, when executed, further cause:

in response to determining that the set of commands is not acceptable for replay, disabling replay and purging the set of commands.

20. The one or more non-transitory storage media of claim 12, wherein one or more commands of the set of commands are sent on the second database session with one or more identifiers of one or more states of the database in which the one or more commands were previously executed on the first database session, and wherein one or more other commands of the set of commands are sent on the second database session for re-execution against current states of the database.

21. The one or more non-transitory storage media of claim 12, wherein the instructions, when executed, further cause:

receiving, on an application programming interface, marked boundaries that delimit requests on a same session from each other where a request is marked with a begin marker at the beginning an an end marker at the end.

22. The one or more non-transitory storage media of claim 12, wherein the instructions, when executed, further cause, after sending the set of commands for execution on the second database session, sending one or more other commands for execution on the second database session, wherein the one or more other commands depend on the state that was exposed to the client on the first database session.

24. The one or more non-transitory storage media of claim 21, wherein the set of commands is a first set of commands, wherein the instructions, when executed, further cause, for a second request comprising a second set of commands, determining whether or not the second set of commands, separately from the first set of commands, is acceptable to replay based at least in part on whether or not the second set of commands satisfies one or more criteria.

28. The one or more non-transitory storage media of claim 12, wherein the instructions, when executed, further cause indicating, to a server, marked boundaries that delimit a beginning and an ending of a request on a dedicated connection.

29. The one or more non-transitory storage media of claim 12, wherein the instructions, when executed, further cause:

at a connection pool that manages server connections for a client driver used by two or more client sessions, automatically marking boundaries that delimit a beginning and an ending of a request, wherein automatically marking the boundaries comprises;

marking the beginning of the request when a connection is checked out from the pool, and

marking the ending of the request when a connection is checked back into the pool.

30. The one or more non-transitory storage media of claim 12, wherein the instructions, when executed, further cause:

at a connection pool that manages server connections for a client application, automatically marking boundaries that delimit a beginning and an ending of a request, wherein automatically marking the boundaries comprises;

marking the beginning of the request when a connection is checked out from the pool, and

marking the ending of the request when a connection is checked back into the pool.

32. The one or more non-transitory storage media of claim 12, wherein the instructions, when executed, further cause, in response to determining that the state has been successfully rebuilt on the second database session, causing operation of an application that originated the set of commands to continue without experiencing an outage.