Merge branch 'iluwatar:master' into master

Author: naman-sriv

leader-followers/src/main/java/com/iluwatar/leaderfollowers/App.java

@@ -1,61 +1,13 @@
-/*
- * This project is licensed under the MIT license. Module model-view-viewmodel is using ZK framework licensed under LGPL (see lgpl-3.0.txt).
- *
- * The MIT License
- * Copyright © 2014-2022 Ilkka Seppälä
- *
- * Permission is hereby granted, free of charge, to any person obtaining a copy
- * of this software and associated documentation files (the "Software"), to deal
- * in the Software without restriction, including without limitation the rights
- * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
- * copies of the Software, and to permit persons to whom the Software is
- * furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
- * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
- * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
- * THE SOFTWARE.
- */
 package com.iluwatar.leaderfollowers;
 
 import java.security.SecureRandom;
 import java.util.concurrent.Executors;
 import java.util.concurrent.TimeUnit;
+import lombok.extern.slf4j.Slf4j;
 
-/**
- * Leader/Followers pattern is a concurrency pattern. This pattern behaves like a taxi stand where
- * one of the threads acts as leader thread which listens for event from event sources,
- * de-multiplexes, dispatches and handles the event. It promotes the follower to be the new leader.
- * When processing completes the thread joins the followers queue, if there are no followers then it
- * becomes the leader and cycle repeats again.
- *
- * <p>In this example, one of the workers becomes Leader and listens on the {@link TaskSet} for
- * work. {@link TaskSet} basically acts as the source of input events for the {@link Worker}, who
- * are spawned and controlled by the {@link WorkCenter} . When {@link Task} arrives then the leader
- * takes the work and calls the {@link TaskHandler}. It also calls the {@link WorkCenter} to
- * promotes one of the followers to be the new leader, who can then process the next work and so on.
- *
- * <p>The pros for this pattern are: It enhances CPU cache affinity and eliminates unbound
- * allocation and data buffer sharing between threads by reading the request into buffer space
- * allocated on the stack of the leader or by using the Thread-Specific Storage pattern [22] to
- * allocate memory. It minimizes locking overhead by not exchanging data between threads, thereby
- * reducing thread synchronization. In bound handle/thread associations, the leader thread
- * dispatches the event based on the I/O handle. It can minimize priority inversion because no extra
- * queuing is introduced in the server. It does not require a context switch to handle each event,
- * reducing the event dispatching latency. Note that promoting a follower thread to fulfill the
- * leader role requires a context switch. Programming simplicity: The Leader/Followers pattern
- * simplifies the programming of concurrency models where multiple threads can receive requests,
- * process responses, and de-multiplex connections using a shared handle set.
- */
+@Slf4j
 public class App {
 
-  /** The main method for the leader followers pattern. */
   public static void main(String[] args) throws InterruptedException {
     var taskSet = new TaskSet();
     var taskHandler = new TaskHandler();
@@ -64,18 +16,23 @@ public static void main(String[] args) throws InterruptedException {
     execute(workCenter, taskSet);
   }
 
-  /** Start the work, dispatch tasks and stop the thread pool at last. */
   private static void execute(WorkCenter workCenter, TaskSet taskSet) throws InterruptedException {
     var workers = workCenter.getWorkers();
     var exec = Executors.newFixedThreadPool(workers.size());
-    workers.forEach(exec::submit);
-    Thread.sleep(1000);
-    addTasks(taskSet);
-    exec.awaitTermination(2, TimeUnit.SECONDS);
-    exec.shutdownNow();
+
+    try {
+      workers.forEach(exec::submit);
+      Thread.sleep(1000);
+      addTasks(taskSet);
+      boolean terminated = exec.awaitTermination(2, TimeUnit.SECONDS);
+      if (!terminated) {
+        LOGGER.warn("Executor did not terminate in the given time.");
+      }
+    } finally {
+      exec.shutdownNow();
+    }
   }
 
-  /** Add tasks. */
   private static void addTasks(TaskSet taskSet) throws InterruptedException {
     var rand = new SecureRandom();
     for (var i = 0; i < 5; i++) {

saga/README.md

@@ -31,6 +31,10 @@ Wikipedia says
 
 > Long-running transactions (also known as the saga interaction pattern) are computer database transactions that avoid locks on non-local resources, use compensation to handle failures, potentially aggregate smaller ACID transactions (also referred to as atomic transactions), and typically use a coordinator to complete or abort the transaction. In contrast to rollback in ACID transactions, compensation restores the original state, or an equivalent, and is business-specific. For example, the compensating action for making a hotel reservation is canceling that reservation.
 
+Flowchart
+
+![Saga flowchart](./etc/saga-flowchart.png)
+
 ## Programmatic Example of Saga Pattern in Java
 
 The Saga design pattern is a sequence of local transactions where each transaction updates data within a single service. It's particularly useful in a microservices architecture where each service has its own database. The Saga pattern ensures data consistency and fault tolerance across services. Here are the key components of the Saga pattern:

saga/etc/saga-flowchart.png

@@ -31,6 +31,10 @@ In plain words
 
 > Defines a client interface separate from its implementation to allow for flexible and interchangeable components.
 
+Sequence diagram
+
+![Separated Interface sequence diagram](./etc/separated-interface-sequence-diagram.png)
+
 ## Programmatic Example of Separated Interface Pattern in Java
 
 The Java Separated Interface design pattern is a crucial software architecture strategy that promotes separating the interface definition from its implementation, crucial for enhancing system flexibility and scalability. This allows the client to be completely unaware of the implementation, promoting loose coupling and enhancing flexibility.

separated-interface/README.md

@@ -32,6 +32,10 @@ Wikipedia says
 
 > In computing, serialization is the process of translating a data structure or object state into a format that can be stored (e.g. files in secondary storage devices, data buffers in primary storage devices) or transmitted (e.g. data streams over computer networks) and reconstructed later (possibly in a different computer environment). When the resulting series of bits is reread according to the serialization format, it can be used to create a semantically identical clone of the original object. For many complex objects, such as those that make extensive use of references, this process is not straightforward. Serialization of objects does not include any of their associated methods with which they were previously linked.
 
+Flowchart
+
+![Serialized Entity flowchart](./etc/serialized-entity-flowchart.png)
+
 ## Programmatic Example of Serialized Entity Pattern in Java
 
 The Serialized Entity design pattern is a way to easily persist Java objects to the database. It uses the `Serializable` interface and the DAO (Data Access Object) pattern. The pattern first uses `Serializable` to convert a Java object into a set of bytes, then it uses the DAO pattern to store this set of bytes as a BLOB (Binary Large OBject) in the database.

separated-interface/etc/separated-interface-sequence-diagram.png

@@ -30,6 +30,10 @@ In plain words
 
 > The Serialized LOB design pattern manages the storage of large objects, such as files or multimedia, by serializing and storing them directly within a database.
 
+Flowchart
+
+![Serialized LOB flowchart](./etc/serialized-lob-flowchart.png)
+
 ## Programmatic Example of Serialized LOB Pattern in Java
 
 The Serialized Large Object (LOB) design pattern is a way to handle large objects in a database. It involves serializing an object graph into a single large object (a BLOB or CLOB, for Binary Large Object or Character Large Object, respectively) and storing it in the database. When the object graph needs to be retrieved, it is read from the database and deserialized back into the original object graph.

serialized-entity/README.md

@@ -34,6 +34,10 @@ Wikipedia says
 
 > In software engineering, the servant pattern defines an object used to offer some functionality to a group of classes without defining that functionality in each of them. A Servant is a class whose instance (or even just class) provides methods that take care of a desired service, while objects for which (or with whom) the servant does something, are taken as parameters.
 
+Sequence diagram
+
+![Servant sequence diagram](./etc/servant-sequence-diagram.png)
+
 ## Programmatic Example of Servant Pattern in Java
 
 The Servant design pattern is a behavioral design pattern that defines a class that provides some sort of service to a group of classes. This pattern is particularly useful when these classes lack some common functionality that can't be added to the superclass. The Servant class brings this common functionality to a group of classes.