Selective Event Publishing in Database Transactions
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing systems publish events in response to database operations regardless of whether the transaction is committed or rolled back, leading to events reflecting operations that were not performed, causing undesirable effects such as spurious actions by consumers.
Innovation Solution
Implementing a system that allows selective publishing of events, where the event is published only after determining if the transaction is committed, and storing or discarding it based on this outcome, thereby expanding the transaction boundary to include or exclude the event publication accordingly.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If an event is published responsive to a database operation in a transaction, then the event is made available to consumers, but the event reflects an operation that was not performed when the transaction is rolled back
Solution Approach 1:
The system performs preliminary action by buffering the event and delaying its publication until the transaction outcome is known. The event is held in a buffer and only published to consumers if the transaction commits, preventing spurious events from being delivered while maintaining efficient batch publishing capability.
2Ease of operation
If an event is published regardless of transaction outcome, then event publishing is simple and fast, but spurious actions occur when the transaction is rolled back
Solution Approach 1:
The system introduces an intermediary buffer between event generation and event publication. This buffer acts as a mediator that temporarily holds events until transaction completion is confirmed, filtering out spurious events while maintaining a simple publish-subscribe interface for consumers.
3Loss of information
If events are published for rolled back transactions, then all database operations are captured, but computing resources are wasted on unnecessary event processing
Solution Approach 1:
The system applies discarding and recovering by holding events in a buffer and selectively discarding those corresponding to rolled back transactions. Events for committed transactions are published to consumers, while events for failed transactions are discarded, preventing waste of computing resources on spurious event processing.
Data Source
AI summary
Implementations are described for selectively publishing an event responsive to an operation on a database in a transaction. Publishing the event is delayed or not delayed respectively, responsive to determining that a value of an attribute for the event indicates that publishing the event is to be delayed, or not to be delayed, until the transaction is rolled back or committed. If publishing the event is delayed, the event is published if the transaction is committed and discarded if the transaction is rolled back. If publishing the event is not delayed, the event is published. Optionally, if the event is published, the event is published in a database or a datastore respectively, responsive to determining whether another value of another attribute for the event indicates that the event is to be published in a database or a datastore.