Use of retry period in an application server to ensure that status information is sent from first to second database instance

• US 20060235853A1
• Filed: 04/14/2005
• Published: 10/19/2006
• Est. Priority Date: 04/14/2005
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: BEA Systems Incorporated (Oracle Corporation)
• Inventors: Luo, Fei
• Granted Patent: US 7,437,361 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: G06F 11/1474 in transactions G06F16/20 takes precedence
• CPC Class Codes: G06F 11/2035 without idle spare hardware
• CPC Class Codes: G06F 11/2097 maintaining the standby controller/processing unit updated initialisation or re-synchronisation thereof G06F11/1658 and subgroups
• CPC Class Codes: G06F 9/466 Transaction processing

Abstract

A retry period can be used in a system that uses a first and second database instance to ensure that the status information from the first database instances has been transferred and updated at the second databases instance.

Claims

1. A server system comprising:

at least one server instance interacting with a number of database instances, the at least one server instance having an associated retry period for situations when a connection with a first database instance fails in an transaction and a connection is made to finish the transaction at a second database instance, the associated retry period being used to ensure that the most recent status information for the transaction has been sent from the first database instance to the second database instance.

2. The server system of claim 1, wherein the transaction is an two phase commit transaction.

3. The server system of claim 1, wherein the transaction is an XA transaction.

4. The server system of claim 1, wherein the transaction is finished by a commit to the second database instance.

5. The server system of claim 4, wherein the commit at the second database instance is repeated within the retry period when a response from the second database instance may indicate that the second database instance may have not been updated with the most recent status information.

6. The server system of claim 1, wherein the transaction is finished by a rollback to the second database instance.

7. The server system of claim 6, wherein the rollback at the second database instance is repeated within the retry period when a response from the second database instance may indicate that the second database instance may have not been updated with the most recent status information.

8. The server system of claim 1, wherein the transaction is finished by a log request to the second database instance for a recover.

9. The server system of claim 8, wherein the log request to the second database instance is repeated within the retry period.

10. The server system of claim 9, wherein the retry period is configurable by an application.

11. A java database connectivity system wherein an associated retry period is used for situations when a connection with a first database instance fails in an transaction and a connection is made to finish the transaction at a second database instance, the associated retry period being used to ensure that the most recent status information for the transaction has been sent from the first database instance to the second database instance.

12. The java database connectivity system of claim 11, wherein the transaction is a two phase commit transaction.

13. The java database connectivity system of claim 11, wherein the transaction is an XA transaction.

14. The java database connectivity system of claim 11, wherein the transaction is finished by a commit to the second database instance.

15. The java database connectivity system of claim 14, wherein the commit at the second database instance is repeated within the retry period when a response from the second database instance may indicate that the second database instance may have not been updated with the most recent status information.

16. The java database connectivity system of claim 11, wherein the transaction is finished by a rollback to the second database instance.

17. The java database connectivity system of claim 16, wherein the rollback at the second database instance is repeated within the retry period when a response from the second database instance may indicate that the second database instance may have not been updated with the most recent status information.

18. The java database connectivity system of claim 11, wherein the transaction is finished by a log request to the second database instance for a recover.

19. The java database connectivity system of claim 18, wherein the log request to the second database instance is repeated within the retry period.

20. The java database connectivity system of claim 19, wherein the retry period is configurable by an application.