You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: Improve transaction handling to prevent concurrent processing and add timeout mechanism (Get Submission)
- Implemented locking to ensure submissions are processed by a single xqueue watcher.
- Added timeout mechanism for submissions stuck in 'pulled' state.
- Updated tests to cover new error scenarios and timeout handling.
We identified a concurrency issue in the submission processing flow. Multiple instances of the xqueue watcher were processing the same transaction simultaneously, causing duplicate handling of submissions. Additionally, submissions remained stuck in the "pulled" state indefinitely when errors or unexpected interruptions occurred during processing.
13
+
14
+
Decision
15
+
--------
16
+
17
+
We introduced a robust locking mechanism at the database level to prevent concurrent processing of the same submission. Specifically, we employed database row-level locking (`select_for_update(nowait=True)`) on submissions to ensure only one xqueue watcher instance can process a transaction at a time. Additionally, we implemented a timeout-based fallback, marking submissions in the "pulled" state as available again if they exceed a defined timeout period (5 minutes).
18
+
19
+
Consequences
20
+
------------
21
+
22
+
Positive
23
+
~~~~~~~~
24
+
25
+
- Ensures data consistency by preventing duplicate transaction processing.
26
+
- Implements automatic recovery for submissions stuck in the "pulled" state, improving overall system reliability.
27
+
- Minimal impact on system performance due to efficient database-level locking.
28
+
29
+
Negative
30
+
~~~~~~~~
31
+
32
+
- Slightly increased complexity in transaction handling logic.
33
+
- Potential minor latency increase when contention occurs due to database locks.
0 commit comments