cfdfedbd2e
* #496 Add pipeline module to parent pom ✨ * #496: Add main application class and test for pipeline * #496: Checkstyle format and add log messages on pipeline stages 🎨 * #496: Fill readme sections of pipeline ✨ * #496: Javadocs and checkstyle formatting 🎨 * #496: Follow PMD checks and add more explanation as block comment on App.java * #496: Apply requested PR changes by iluwatar 🎨 * #970: Replace log4j usage on commander pattern to Slf4j API 🎨 * #970: Replace log4j usage on dao pattern to Slf4j API 🎨 * #970: Replace log4j usage on data mapper pattern to Slf4j API 🎨 * #970: Remove log4j dependency on data transfer object pom 🔥 * #970: Replace log4j usage on module pattern to Slf4j API 🎨 * #970: Replace log4j usage on serverless pattern to Slf4j API 🎨 This also removes the aws log4j dependency * #970: Remove unnecessary gitignore line for log4j.xml 🔥 * #970: Remove remaining remnants of log4j 🔥 * #970: Replace System.out logging with appropriate logging methods 🎨 * #970: Replace System.out method references to Logger::info 🎨
layout, title, folder, permalink, categories, tags
| layout | title | folder | permalink | categories | tags | ||
|---|---|---|---|---|---|---|---|
| pattern | Commander | commander | /patterns/commander/ |
|
Intent
Used to handle all problems that can be encountered when doing distributed transactions.
Applicability
This pattern can be used when we need to make commits into 2 (or more) databases to complete transaction, which cannot be done atomically and can thereby create problems.
Explanation
Handling distributed transactions can be tricky, but if we choose to not handle it carefully, there could be unwanted consequences. Say, we have an e-commerce website which has a Payment microservice and a Shipping microservice. If the shipping is available currently but payment service is not up, or vice versa, how would we deal with it after having already received the order from the user? We need a mechanism in place which can handle these kinds of situations. We have to direct the order to either one of the services (in this example, shipping) and then add the order into the database of the other service (in this example, payment), since two databses cannot be updated atomically. If currently unable to do it, there should be a queue where this request can be queued, and there has to be a mechanism which allows for a failure in the queueing as well. All this needs to be done by constant retries while ensuring idempotence (even if the request is made several times, the change should only be applied once) by a commander class, to reach a state of eventual consistency.