|
|
|
|
|
|
by mountainreason
1261 days ago
|
|
|
I dont have an answer, I'm just curious about something. I thought that the point of an outbox was that it was local, and could therefore be updated atomically along with any local db changes. What would happen if the orchestrator was unable to update the remote shared cache outbox after a local exception/rolled back transaction? |
|
|
To be sure, I understand your question, you are referring to the following scenario:
- Start global transaction
- Create shared cache entry
- Add events to the shared cache
- Local transaction fails
- Orchestrators starts rolling back local transaction
- Attempts to delete shared cache entry <-- THIS ONE FAILS
To ensure we don't have stale events in the cache, I would add a TTL, which is configurable for each job (such that you can have long-living events). So in case the orchestrator fails to delete the cache entry, they would be invalidated at some point by exceeding its TTL.