This page the plan for testing the re-trial and fail-over mechanisms in CORAL.
Use Case | Test Case | Expected Result |
---|---|---|
The database server is temporarily unavailable when an application tries to access it for the first time. The application re-tries a few times before it eventually manages to connect. | A test application connects to the database, performs a query and disconnects. The ConnectionService is configured such that it allows for a few re-tries and some time for the server to be accessible, before throwing an exception. The listener of an Oracle database is stopped before the launching of the application and restarted a bit afterwards, within a time window that is smaller than the timeout specified in the ConnectionService configuration. |
The test application always manages to issue the query against the specific server with the expected result. |
The nominal database server is unavailable when an application tries to access it for the first time. The application re-tries a few times before it eventually reverts to another server to which it manages to connect. | A test application connects to the database, performs a query and disconnects. The ConnectionService is configured such that it allows for a few re-tries and some time for the server to be accessible, before reverting to the next available replica. The listener of an Oracle database is stopped before the launching of the application, while the second server is up. |
The test application always manages to issue the query with the expected result. |
The database server becomes temporarily unavailable during the running of an application in a time window, where there is no interaction with the database. The application re-tries a few times before it eventually manages to continue normally the read-only operations. | A test application receives a connection handle to connects to the database, performs a query and releases the connection handle. After some time, it repeats another read-only operation and finally exits. The ConnectionService is configured such that it allows for a few re-tries and some time for the server to be accessible, before throwing an exception. The instance of an Oracle database is brought down after the first activity happens in the application and is brought up again after the second activity happens within a time window that is smaller than the timeout specified in the ConnectionService configuration. |
The test application always manages to issue both queries against the specific server with the expected result. |
The nominal database server becomes unavailable during the running of an application in a time window, where there is no interaction with the database. The application re-tries a few times before it reverts to the use of another replica and eventually manages to continue normally the read-only operations. | A test application receives a connection handle to connects to the database, performs a query and releases the connection handle. After some time, it repeats another read-only operation and finally exits. The ConnectionService is configured such that it allows for a few re-tries and some time for the server to be accessible, before reverting to the next available replica. The instance of an Oracle database is brought down after the first activity happens in the application. |
The test application always manages to issue both queries with the expected result. |
The listener of an Oracle database server becomes unavailable after an application has connected for the first time. The application continues to use the connection. | A test application receives a connection handle to connects to the database, performs a query and releases the connection handle. After some time, it repeats another read-only operation and finally exits. The listener of an Oracle database is brought down after the first activity happens in the application. |
The test application always manages to issue both queries against the specific server with the expected result. |