| Item |
Section |
Comment |
Response |
| kasso-01 |
4.1 |
Is there a more detailed description of how the automated recovery will work? Specifically what's the default location for TX_LOG_DIR? |
It will work the same way as in v2.x - A special listener on each instance will listen to GMS notifications about failure in another instnce, and if delegated transaction recovery is enabled, will start the process from the instance that got the notification. There is no default for TX_LOG_DIR. |
| kasso-02 |
4.1 |
IF the first instance crashes during recovery what triggers the second instance to take over the recovery operation? |
The GMS notification includes name of the failed instance. In v2 it was "fencing" mechanism that kept the knowledge about the 1st instance. In 3.1 we'll keep it in a special file as described in this section. |
| kasso-03 |
4.1 |
How does the second instance know the first instance is no longer performing the recovery? Is it possible to get into a scenarios where two instances are trying to perform recovery for the same txn? |
If GMS sends a crash notification, it means that the 1st instance didn't restart, and as such, it can't perform a recovery. |
| kasso-04 |
4.1 |
The spec says the new code should also allow for an extension to support DB based transaction logging. Does "should" here really mean will? Will it be documented who to write such an extension? |
It will be for internal purpose only. |
| kasso-05 |
4.1 |
It is not clear to me when automated recovery is enabled vs using manual recovery? Is this covered in the 2.1.1 docs? |
If we do not support automated recovery, we'll document the limitation. |
| tmueller-01 |
4.6 |
I didn't understand the reference here to storing transaction logs in a database, since this project is handling the shared file system case only (per seciton 4.3). |
The current docs (incorrectly) say that it's very well possible to store tx logs in the database without any limitations. I updated the section. |
