introduce
I started allocating and reading 100 columns and 100,000 rows of CSV files and writing them to the database.
Method 1: A simple Java program
So I start with a simple Java program, run a while loop up to EOF, and then make a JDBC call to store the values. This took about an hour to complete, but then I realized that the program took longer to run than it did to create. So the task is not as easy as it looks. So what can be done? Of course, I realized THAT I needed to do things in parallel.
Method 2: Threaded Java programs
Threads have always seemed complicated to me. The concept of “Mutex”, “Semaphores” and “Monitors” scares me. So I’m trying to understand the concept. Java uses Monitors for synchronization. Java Monitors support two kinds of thread synchronization: mutually exclusive and cooperative.
Mutually exclusive operations supported in Java through virtual machine object locks enable multiple threads to independently process shared data without interfering with each other. Cooperation is achieved through waiting and notification. This approach enables threads to work together towards a common goal.
The Monitor area
When a thread reaches the beginning of the monitor area, it is placed in the set of entries for the relevant monitor. This set is like a queue at a bank counter. When a person arrives at the front of the line, they can make a transaction.
Every lecture or article on threads mentions consumer and producer issues. So my question is similar, right? I have a reader (producer) that reads a row and provides it to the JDBC layer (consumer) to write to the database.
Java already provides blocking queues to make implementation problems easier. But I can’t generate 100,000 threads to do that. I need something like a thread pool to limit the number of threads. A simple loop and thread count will do. The solution looked good, architecturally very 📃, and THEN I realized THAT I had forgotten error handling. Now I realize that handling exceptions in a thread is very difficult because they don’t return anything. Do they have any other options? So, yes, Java 1.5 has a “callable interface” feature that runs as a thread but goes back to the future. But that’s another story.
Approach 3: Use Java programs with actors
Performing the above tasks made me realize how difficult it would be to maintain this code as complexity increased. In addition, Java uses system threads for each generated thread. So there’s a finite number of generating threads.
What I need is a framework that provides me with concurrent processing, and I can only focus on the business logic part of it. I found one: Akka. Akka is based on the Erlang Actor model. If you read how the problem is implemented above, the pull strategy is implemented and the consumer thread will execute the new task after completing the current one. So we need to wait until the producers are ready. Wouldn’t it be easy if the system were more reactive? For each event, the event handler should be ready to do its job.
So, similarly to banks, we used to stand in a queue, and banks had a hard time maintaining the queue. Sometimes customers get tired of waiting in line and leave. So what the bank can do is refer the problem to a third-party vendor and seek a solution. The vendor recommends using a token system. Have all customers sit in chairs until their code names appear. This sounds like a good solution for the banks, and to add to the icing on the cake, vendors are even prepared to maintain the system for free. Think of the joy that banks would feel. After Akka, I felt a similar joy. Akka is based on actors, so what are actors?
Actors
Actors bring you:
- Simple and advanced concurrency and parallel abstractions.
- Asynchronous, non-blocking, and high-performance event-driven programming model.
- Very lightweight event-driven processes (millions of actors per GB of heap memory).
Akka is very easy to use. It can be added as a dependency to our project.simple JAR file. So let’s get our hands on it and write a Hello World program. Examples are from the Akka documentation.
Let’s define an actor, Greeter:
Greeter extends UntypedActor {
String greeting = "";
public void onReceive(Object message) {
if (message instanceof WhoToGreet)
greeting = "hello" + ((WhoToGreet) message).who;
else if (message instanceof Greet) // //Send the current greeting back to the sender
getSender().tell(new Greeting(greeting), getSelf());
else unhandled(message)
}
}
Copy the code
Yeah, that’s it. It just needs to implement the onRecieve method so that it reacts to the tell call.
So, to get started with this actor, you need to create an actor system:
final ActorSystem system = ActorSystem.create("helloakka");
// Create the greeter actor
final ActorRef greeter = system.actorOf(Props.create(Greeter.class), "greeter");
// Tell the greeter to change its greeting message
greeter.tell(new WhoToGreet("akka"));
Copy the code
Therefore, by using the tell method, you can invoke it. So Akka guarantees that the OnReceive method is called only once at a time. It’s that simple. You don’t have to worry about synchronization.
Akka is a very scalable software, not only in terms of performance, but also in terms of its useful application size. The core of Akka, Akka-actors, is very small and easy to fit into existing projects, and you need asynchronous and lockless concurrency without trouble. “Remoting” does seem to make sense, right?
Everything in Akka is designed to work in a distributed environment: all interactions with actors use pure messaging, and everything is asynchronous. Actors allow you to manage service failures (Supervisors), load management (exit policies, timeouts, and processing isolation), and horizontal and vertical scalability (adding more kernels or machines).
Actors tend to be better suited for parallel processing units that are less CPU-demanding and may be better suited for distributed parallel computing (higher latency but higher throughput). So I feel really good about using actors, which are faster than traditional threads.
dzone.com/articles/co…
See more articles
Public id: Galaxy 1
Contact email: [email protected]
(Please do not reprint without permission)