-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Catalog and Routing
-
200
In a process running with an embedded router, the router and shard roles will share a TransactionRouter object because the TransactionRouter is a decoration on the Session which is shared across both. In a world without embedded routers, we expect that a router who has not participated in a given transaction knows nothing about that transaction. But now, if the shard acted as a sub-router for a given transaction, the embedded router will have access to state about the transaction.
This is mainly a problem if a client starts a transaction on one router, but then later runs the recovery protocol through an embedded router on a process where the shard role had acted as a subRouter in the transaction being recovered. A TransactionRouter object which is a sub-router should not be allowed to run the commit or abort protocol because a sub-router will not know of all of the participants, but a TransactionRouter running on an embedded router role should be allowed to run the recovery commit protocol, even if the shard role on that process acted as a sub-router. However today, if a shard acts as a sub-router in a transaction, it creates a TransactionRouter object and sets a flag subRouter on it. If commit or abort are called on this TR object when the subRouter flag is set, the TR will fail the commit or abort. So, if a client tries to recover a commit decision through an embedded router that is running on a process where the shard acted as a sub-router, we’ll fail that request.
We should make it so that a router and shard role do not share a TransactionRouter object.