transaction-outbox | Reliable eventual consistency for Microservices | Microservice library
kandi X-RAY | transaction-outbox Summary
kandi X-RAY | transaction-outbox Summary
A flexible implementation of the Transaction Outbox Pattern for Java. TransactionOutbox has a clean, extensible API, very few dependencies and plays nicely with a variety of database platforms, transaction management approaches and application frameworks. Every aspect is highly configurable or overridable. It features out-of-the-box support for Spring DI, Spring Txn, Guice, MySQL 5 & 8, PostgreSQL 9-12 and H2.
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
- Executes the given task
- Log a message at the specified level
- Updates the attempt count
- Returns a description for the task
- Saves an entry in the table
- Sets the insert statement
- Deserialize an invocation
- Replace immutable collections
- Creates a thread - local transaction manager
- Creates a new transaction
- Deserialize a TransactionOutboxEntry
- Deserialize an invocation from a reader
- Creates an adapter for the given type
- Registers a subtype
- Unblock the given entry
- Deletes an entry from the table
- Add custom serializers
- Obtain a connection to the driver
- Perve the Invocation instance
- Invoke a method on an object instance
- Updates an entry in the table
- Rehires an invocation within a transaction
- Joins this listener with another listener
- Validates the request
- Retrieves the active transaction from the given context
- Lock an entry in the transaction table
transaction-outbox Key Features
transaction-outbox Examples and Code Snippets
Lines of Code : 82License : Permissive (Apache-2.0)
CopyTransactionManager transactionManager = TransactionManager.fromDataSource(dataSource);
TransactionOutbox outbox = TransactionOutbox.builder()
// The most complex part to set up for most will be synchronizing with your existing transaction
//
github-transaction-outbox
Gruelbox Github Repository
https://maven.pkg.github.com/gruelbox/transaction-outbox
github-transaction-outbox
${env.GITHUB_USERNAME}
${env.GITHUB_TOKEN}
repositories Thread backgroundThread = new Thread(() -> {
while (!Thread.interrupted()) {
try {
// Keep flushing work until there's nothing left to flush
while (outbox.flush()) {}
} catch (Exception e) {
log.error("Error flushing tr Community Discussions
Trending Discussions on transaction-outbox
QUESTION
We did some load tests on a Saga with a In-Memory outbox. During those tests we simulated different types of failures: application restarts, infrastructure restart, message broker restart etc.
We noticed, that some saga instances did not finish and we had a bunch of errors: Automatonymous.NotAcceptedStateMachineException: ... {SomeEvent}: Not accepted in state {SomeState}
After some debuging we isolated the problem. I'll try to describe it using this sample code:
...ANSWER
Answered 2020-Feb-23 at 19:19Since you've read the article on using the outbox, and you realize that you need to add a handler for Submit to the Submitted state, that's really the answer. However, unlike the original handler which updated the saga state and was persisted, you only need to regenerate the events that were sent/published. That handles the first part of the problem, Submitted.
The second part is a different answer, and it is pretty simple actually. You don't finalize the order in Accept. You create an additional state, Accepted, that the order transitions to after being accepted. And you remove the order instances after a period of time (a week, a month, whatever). That way, when the Accept message is delivered to the Accepted instance, you can regenerate the events that were published.
Now, you could use Quartz to schedule a future message to finalize the saga, which doesn't do any business logic, but only removes the saga instance. And you could set up an Initially(When(RemoveOrder).Ignore()) handler that would discard the remove order message if the saga doesn't exist. And that makes it automatic. But in past systems we've just archived a date range partition of the file group (in SQL server) or deleted the older records after 30 or 90 days or whatever.
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install transaction-outbox
At the moment, if any work fails first time, it won't be retried. All we need to add is a background thread that repeatedly calls TransactionOutbox.flush() to pick up and reprocess stale work.
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page
