dyslexicanaboko / protected-resource Goto Github PK

Main issues

• What to do when a transaction fails?
• What happens if the transaction keeps failing though?

Idea 1

1. Retry database update depending on the error? If it was a deadlock, cannot retry for example.

Idea 2

1. Updated cached copy.
2. Put squashed message back on the queue but as next to process (first in line).
3. New squash with new chunk
4. New table update

When a requestor submits a message there needs to be a message sent back giving them a clue as to what happened to their request.

• Was it squashed?
• What does it look like after the squash?
• In general it will give them confirmation their change went through somehow.

Setting up a demo to help explain how this works.

Each table manager needs to be monitored for health.

1. If the table manager crashes, the resulting exception should not take down the whole service
2. The exception needs to be logged
3. The table manager should try to restart a fixed number of times before staying down
4. Additionally, if there is a dead lock exception or other type of exception when a transaction is being committed; it needs to be determined how many times this can happen before a partition is considered critical.
5. Should there be a global metric that handles the over all health of the table manager based on the health of the individual partitions?

• Each time a partition is updated, an update statement is created.
• It would be beneficial to just store all combinations that are created the first time to not have to generate them again since this is technically an expensive operation.
• Benefits are, not using reflection for each commit.