Develop Reference

An effective way to implement Threads in Java on many DB records

I am in the development stages of an experimental system in Java with a heavy MySQL DB, containing thousands of records, for each of which is required to perform a number of operations, and in parallel.
I'm well aware of using Java Threads, but I do not know what is the best/efficient way to use it on masses of records from DB.
Suppose we look at the following DB table:
Table technicians
ID NUMBER
DISTRICT_CODE NUMBER NOT NULL
EVENT_START_DATE DATE NOT NULL
EVENT_END_DATE DATE NOT NULL
INCHARGE NUMBER NOT NULL
EFFECTIVE_FROM DATE DEFAULT SYSDATE NOT NULL
EFFECTIVE_TO DATE
STATUS NUMBER NOT NULL
Then we'll perform the following extraction:
SELECT * FROM technicians WHERE INCHARGE = 23;
Now, I'm now seriously debating whether to put the extracted info into a List (for example, ArrayList), or other data structure, (Note that each extraction contains about 4000 records, and it occurs every 3 seconds over and over again) and how to implement Thread for each of the records individually.
The naive idea that has been raised, is that after querying the DB and receiving the information, go through each record entry in a loop (sql.hasNext () e.g.) and run the ThreadPoolExecutor object on each record, but I tend to believe that there are more efficient and faster ways.
Any suggestion is welcome
Edit: I see questions have been raised about the actions to be taken for each of the records, so I will try to answer that.
For each line, we will run several different APIs for each field to ensure its correctness type of answer (e.g. correct, incorrect, correct but the value is short, etc.) on so on.
It is important for me to note that each of the actions occurs towards an API that is external to the system (located on a different remote server), so sometimes for a single field, several calls to different APIs will be made, so high power and parallel work are important.
For example:
For the INCHARGE field - we will send the value to an external API source that will check the data, and if the information is correct then we will send the field again to another API and we will get information related to it.

Better design:
Don't use cron or Events for a repeating task that might take longer than the allotted interval to finish.
Instead, have a separate program that runs through all 4000 items (taking as long as needed), then starts over.
Further comments:
It may not matter much whether you use multi-processing versus multi-threading.
If threading, remember that MySQL connections are not thread-safe; you must use a separate connection for each thread.
While MySQL can easily handle 4000 idle connections, it does not do well with 4000 queries active simultaneously. (Often 100 is challenging for it. Often, the solution is to speed up the queries.)
Splitting the 4000 into multiple threads may not be useful. It is rarely useful to have more threads than CPU cores. They stumble over each other in new ways -- how the OS deals with coordination.
Splitting up the 4000 complicates this extra process -- You may need a master program that is watching its children to see when it is time to start over. Or (probably better), have, say, 20 threads each doing a specific 200 tasks.

It seems you want to process some rows in a database every three seconds. For each time, you want to query for about four thousand rows. Each of those rows needs to be individually processed, without regard for the other rows in that table. It sounds like you are not updating the rows, but instead sending the row’s data via calls to other services such as making web services calls.
Yes, use executor services
So load you data into memory, as the volume seems low. Define a class to hold the data for each row. Since we are using this class primarily to communicate data transparently and immutable, define the class as a record.
record Technician ( int id , LocalDate eventStart , … ) {}
Instantiate these Technician objects as you loop the result set from your query.
For each Technician object, pass to the constructor of a class implementing Callable. The run method of that class defines the work you need to do in processing that row’s data, passing to web service calls, etc.
A Callable returns a value. Let's define another record to signal success/failure and the ID of the record.
record TechnicianProcessingResult ( int id , boolean succeeded ) {}
Make that record be the type of our Callable.
class ProcessTechnicianTask implements Callable< TechnicianProcessingResult > {
private final Technician technician ;
ProcessTechnicianTask( Technician t ) { // Constructor.
this.technician = t ;
}
public TechnicianProcessingResult call() {
System.out.println( "Processing technician Id " + this.technician.id );
…
return new TechnicianProcessingResult( this.technician.id , true ) ;
… or …
return new TechnicianProcessingResult( this.technician.id , false ) ;
}
}
Instantiate a task for each Technician object you instantiated for each row retrieved from database. Collect the tasks.
List< ProcessTechnicianTask > tasks = new ArrayList<>() ;
…
tasks.add( new ProcessTechnicianTask( nthTechnician ) ) ;
Submit that collection of tasks an executor service you have already established. Generally specify almost as many threads as you have CPU cores available.
ExecutorService executorService = Executors.newFixedThreadPool( 5 ) ;
…
List< Future< TechnicianProcessingResult > > futures = executorService.invokeAll( tasks , 3 , TimeUnit.SECONDS ) ;
Notice the time-out arguments, to fire in case something goes wrong and your tasks take too much time to complete.
Check the list of futures to see if they are done, and if any were canceled, and check their result object.
You want to repeat that every three seconds. So also create a single-threaded ScheduledExecutorService. Schedule a repeating task, a Runnable or Callable, that does the above work of database query, instantiating Technician objects, assigning each to a ProcessTechnicianTask object, all submitted to our other executor service.
Be sure to gracefully shutdown your executor service objects. Otherwise their backing thread pools may continue running indefinitely, like a zombie 🧟‍♂️. See boilerplate code provided in the Javadoc.
All of this has been covered many times already on Stack Overflow. So search to learn more.
You seemed to have had this approach in mind. But you wondered if there is "more efficient and faster ways". No, I do not see any better way. Your bottleneck here is making network calls to your API, presumably web services calls. Creating the record objects, collecting them, and submitting them to the executor services will be very fast compared to the threads waiting around for a response back from the network calls.
Project Loom
The one thing that might dramatically improve performance in your scenario is the virtual threads and structured concurrency promised by Project Loom.
In current Java, each Java thread is mapped directly to a host OS thread. Each of your few threads will sit idle during the web services calls, halting execution until those calls return. These threads are heavyweight, so we cannot have very many.
In Project Loom, many virtual threads are mapped to each host OS thread. These virtual threads are lightweight, so we can have thousands, even millions. When a virtual thread blocks, such as waiting for your web services call to return, that virtual thread is "parked"/"dismounted" from the host OS thread so that another virtual thread might use the host thread. So other virtual threads can get stuff done while the previous virtual thread waits for its web services call to return.
In your situation, many more web services calls could be placed at a time, rather than only a few at a time. The CPU cores on your machine stay much busier, getting more of your rows processed in less time. You might see a multiple-fold improvement in your processing time.
Project Loom is unfinished, but under active development. Experimental builds are available now, based on early-access Java 19. See articles, interviews, and presentations with team members including Ron Pressler and Alan Bateman.

How to achieve concurrency in java?

Suppose I am working in a banking domain and I have three customers say A,B,C.
Balance of A= Rs.100 Balance of B= Rs.0 Balance of C=Rs.100
Now both A and C are sending money to B at same time. The code for increasing the balance runs concurrently.
When A sends money to B, a call is made to DB which gets its current balance i.e Rs.0
At the same time C sends money to B and call is made to DB which also returns current balance as Rs.0.
So when control is back from DB for "A" and money is added in B's account,
it will be
Balance=Current Balance+ Money Received
so balance= 100.
Again when control is back from DB for "C",
balance = Rs.100 since current balance fetched by this request was also Rs.0
How to handle such scenarios?

A simple UPDATE account SET balance=balance+100 WHERE userId = ? would make sure that the balance is increased properly even in concurrent scenarios.
Only if you retrieve the balance to increase it in Java code you need to make special precautions, but that would be the more complex solution.

First of all, Concurrency is achieved by implementing it into the send method. So in your example there is nothing to achive, because there is already a concurrent setup. It would not be concurrent if the send commands go into a pipeline and being processed one after one.
The problem you experience is a dirty write/dirty read to/from the database Therefore a transaction isolation is needed. Usually a database checks this circumstance and locks the row that is written to. Theoretically you could trust the database, when it offers transactions. It would be a bad practice and unnecessary to double check this. When not you should implement locks (which could get a performance problem, because of intensive locking) and synchronize the access to customer accounts.
To syncronize you could take the addBalance method:
synchronized void addBalance(int amount, CustomerAccountEntity customer) {
//getCustomerBalance
balance = balance+amount;
}

"Select for update" and update with pessimistic locking

I'm trying to implement pessimistic locking using select for update, as I want other threads to wait until the lock on the selected row is released.
The part that I have understood is after going through multiple threads Spring JDBC select for update and various similar threads is it is achievable in case select and update are happening within same method and hence they are part of same transaction.
The issue in my case is I have a JAR for DAO functionality where in a selectforUpdate method is available and a separate update method is available, both method has a finally block which contains
resultSet.close();
statement.close();
connection.close();
Now I'm struggling to find out is there a way in which I can use both the methods from outside of the JAR, maybe by annotating my method with #Transactional annotation and make it work in some way. So that lock is only released once update method has been executed.

You're making a mistake. Using the wrong tool for the job. Transaction levels and FOR UPDATE has the purpose of ensuring data integrity. Period. It it isn't designed for control flow and if you use it for this, it will bite you in the butt sooner rather than later.
Let me try to explain what SELECT FOR UPDATE is for, so that, when later I tell you that it is most definitely not for what you're trying to do with it, it is easier to follow.
Imagine a bank. Simple enough. The bank has some ATMs out front and a website where you can see your transactions and transfer money to other accounts.
Imagine you (ABC) and I (Reinier) are trying to fleece the bank some. Here is our plan: We set it up so that you have €1000,- in your account and I have nothing.
Then, you log into the website from your phone, and start a transfer, transferring €1000,- to my account. But, while you're doing that, right in the middle, you withdraw €10,- from the ATM.
If the bank messed up their transactions, it's possible you end up with €990,- in your account and I have €1000,- in my account, and we fleeced the bank. This is how that could happen (and if halfway through the example you think: I already know this stuff, I know what FOR UPDATE does! - I'm not so sure you do, read it carefully)
ATM code
startTransaction();
int currentBalance = sql("SELECT balance FROM account WHERE user = ?", abc);
if (currentBalance < requestedWithdrawal) throw new InsufficientFundsEx();
sql("UPDATE account SET balance = ? WHERE user = ?", currentBalance - requestedWithdrawal, abc);
commit();
moneyHopper.spitOut(requestedWithdrawal();
Website code
startTransaction();
int balanceTo = sql("SELECT balance FROM account WHERE user = ?", reinier);
int balanceFrom = sql("SELECT balance FROM account WHERE user = ?", abc);
if (transfer > balanceFrom) throw new InsufficientFundsEx();
sql("UPDATE account SET balance = ? WHERE user = ?", balanceTo + transfer, reinier);
sql("UPDATE account SET balance = ? WHERE user = ?", balanceFrom - transfer, abc);
commit();
controller.notifyTransferSucceeded();
How it can go wrong
The way it goes wrong is if the balanceTo and balanceFrom are 'locked in', then the ATM withdrawal goes through, and then the update SQL statements from the website transaction go through (this wipes out the ATM withdrawal, effectively - whatever the ATM spit out is free money), or if the ATM's balance check locks in, then the transfer goes through, and then the ATM's update goes through (which gives the recipient, i.e. me their €1000,-, and ensures that the ATM code's update, setting your balance to 990, is the last thing that happens, giving us €990,- of free money.
So what's the fix? Hint: Not FOR UPDATE
The fix is to consider what a transaction means. The purpose of transactions is to turn operations into atomic notions. Either both your account is reduced by the transfer amount and mine is raised by the same, or nothing happens.
It's obvious enough with statements that change things (UPDATE and INSERT). It's a bit more wonky when we talk about reading data. Should those reads be considered part of the transaction?
One way to go is to say: No, unless you add FOR UPDATE at the end of it all, in which case, yes - i.e. lock those rows only if FOR UPDATE is applied until the transaction ends.
But that is not the only way to ensure data integrity.
Optimistic locking to the rescue - or rather, to your doom
A much more common way is called MVCC (MultiVersion Concurrency Control) and is far faster. The idea behind MVCC (also called optimistic locking), is to just assume no clashes ever occur. Nothing is ever locked. Instead, [A] all changes made within a transaction are completely invisible to things running in any other transaction until you commit, and [B] when you COMMIT a transaction, the database checks if everything you have done within the span of this transaction still 'holds up' - for example, if you updated a row within this transaction that was also modified by another transaction that has committed already, you get an error when you commit, not when you ran the UPDATE statement.
In this framework, we can still talk about what SELECT even means. This, in java/JDBC, is called the Transaction Isolation Level and is configurable on a DB connection. The best level, the level the bank should be using to avoid this issue, is called the TransactionLevel.SERIALIZABLE. Serializable effectively means everything dirties everything else: If during a transaction you read some data, and when you commit, that same SELECT statement would have produced different results because some other transaction modified something, then the COMMIT just fails.
They fail with a so-called 'RetryException'. This means literally what it says: Just start your transaction over, from the top. It makes sense if you think about that bank example: What WOULD have happened, had the bank done it right and set up serializable transaction isolation level, is that either the ATM machine's transaction or the transfer transaction would get the retryexception. Assuming the bank wrote their code right and they actually do what the exception tells you to (start over), then they would start over, and that includes re-reading the balances out. No cheating of the bank can occur now.
Crucially, in the SERIALIZABLE model, locking NEVER occurs, and FOR UPDATE does not mean anything at all.
Thus, usually, FOR UPDATE does literal stone cold nothing, a complete no-op, depending on how the db is setup.
FOR UPDATE does not mean 'lock other transactions that touch this row'. No matter how much you want it to.
Some DB implementations, or even some combination of DB engine and connection configuration may be implemented in that fashion, but that is an extremely finicky setup, and your app should include documentation that strongly recommends the operator to never change the db settings, never switch db engines, never update the db engine, never update the JDBC driver, and never mess with the connection settings.
That's the kind of silly caveat you really, really don't want to put on your code.
The solution is to stop buttering your toast with that chainsaw. Even if you think you can manage to get some butter on that toast with it, it's just not what it was made for, like at all, and we're all just waiting until you lose a thumb here. Just stop doing it. Get a butterknife, please.
If you want to have one thread wait for another, don't use the database, use a lock object. If you want to have one process wait for another, don't use the database, don't use a lock object (you can't; processes don't share memory); use a file. the new java file IO has an option to make a file atomically (meaning, if the file already exists, throw an exception, otherwise make the file, and do so atomically, meaning if two processes both run this 'create atomically new file' code, you have a guarantee that one succeeds and one throws).
If you want data integrity and that's the only reason you wanted pessimistic locking in the first place, stop thinking that way - it's the DBs job, not your job, to guarantee data integrity. MVCC/Optimistic locking DBs guarantee that the bank will never get fleeced no matter how hard you try with the shenanigans at the top of this answer and nevertheless, pessimistic locking just isn't involved.
JDBC itself sucks (intentionally, a bit too much to get into) for 'end use' like what you are doing here. Get yourself an abstraction that makes it nice such as JDBI or JOOQ. These tools also have the only proper way to interact with databases, which is that all DB code must be in a lambda. That's because you don't want to manually handle those retry exceptions, you want your DB access framework to take care of it. This is what the bank code should really look like:
dbAccess.run(db -> {
int balance = db.sql("SELECT balance FROM account WHERE user =?", abc);
if (balance < requested) throw new InsufficientBalanceEx();
db.update("UPDATE account SET balance = ? WHERE user = ?", balance - requested, abc);
return requested;
};
This way, the 'framework' (the code behind that run method) can catch the retryex and just rerun the lambda as often as it needs to. rerunning is tricky - if two threads on a server both cause the other to retry, which is not that hard to do, then you can get into an endless loop where they both restart and both again cause the other to retry, at infinitum. The solution is literally dicethrowing. When retrying, you should roll a random number and wait that many milliseconds, and for every further retry, the range on which you're rolling should increase. If this sounds dumb to you, know that you're currently using it: It's how Ethernet works, too (ethernet uses randomized backoff when collisions occur on the wire). Ethernet won, token ring lost. It's the exact same principle at work (token ring is pessimistic locking, ethernet is optimistic 'eh just try it and detect if it went wrong, then just redo it, with some randomized exponential backoff sprinkled in to ensure you don't get 2 systems in lock-step forever screwing up the other's attempt).

Java Nonsynchronized threads using the same resource

I have to make a very simplified Joint Bank Account program (in this example with 3 users who all have access to the bank accounts resources) but I'm having trouble correctly using Java threads.
Here is how the program should work. There are "users" that all have access to one Joint Bank Account with an arbitrary set initial balance(I used 5000). They can each withdraw or deposit money (whether they withdraw or deposit is randomly generated each time) three times over one run of the program.
The amount they deposit or withdraw is also randomly generated, with the only rule for that being that the amount can never exceed 1/3rd of the current balance.
Finaly after each transaction the current Thread has to "wait" a random amount of seconds between 1 and 10.
Now here is the confusing part. Our teacher asked us to make a unique NotEnoughBalance exception class in case one of the users somehow withdraws more money than what is currently in the account (but here is my first point of confusion: in theory this could never occur due to the 1/3rd rule).
Here is the full code posted on pastebin:
http://pastebin.com/Upam56NF
Currently, when I run the main:
public class BankAccount{
public static void main(String[] args) throws InterruptedException{
int capital = 5000;
JointBankAccount acc = new JointBankAccount(capital);
Thread t1 = new Thread(new Owner("Josh", acc));
Thread t2 = new Thread(new Owner("Wade", acc));
Thread t3 = new Thread(new Owner("Ben", acc));
System.out.println(capital);
String tname = Thread.currentThread().getName();
System.out.println(tname);
t1.start();
t2.start();
t3.start();
t1.join();
t2.join();
t3.join();
for(AccountTransaction s : acc.history){
System.out.println(s.toString());
}
System.out.println(acc.getBalance());
}
}
I randomly sometimes get a NPE exception at System.out.println(s.toString()).
This is completely fixable if I make both deposit and withdraw function Synchronized.
The problem is, somehow I think makign them synchronized defeats the purpose of what our teacher is asking. If I make them synchronized, then I feel like I'm ensuring that the 1/3rd rule gets sucessfuly followed with each withdrawal correctly, and the not enough Balance exception can never exist.
The fact that I get NPEs when I remove synchronized also makes me think possibly the error is in me not properly handling the exception when it does occur. I don't know.
Any help would be greatly appreciated.

This looks to me like a fine exercise in understanding atomic transactions.
But first the NPE: one JointBankAccount instance is shared between several threads, and thus anything contained by the JointBankAccount like the history list. The history list is of type ArrayList which is not thread-safe, i.e. if two threads call the add method at the same time, the list breaks. This is easy to fix though: List<AccountTransaction> history = Collections.synchronizedList(new ArrayList<AccountTransaction>());
Now for the atomic transactions. Since the balance can be changed at any time by any thread, the moment you read the balance, the balance is already outdated. I.e. a statement like if (balance > 1000) then updateBalance() is not valid since the balance could have changed after then. One way to circumvent this is to synchronize everything (although even then you have to be careful, e.g. use AomticInteger to register the balance). But the NotEnoughBalanceException implies a different way of working using a ReentrantReadWriteLock. Before the balance is updated, use a read-lock to read the latest balance and apply any rules to determine if the balance can be updated. This allows you to inform the "owner" that the balance can probably be updated. But since you used a read-lock you cannot be certain: the balance might have already been updated. Now use a write-lock and apply the rules again. This time you can be certain about the balance value (it can only be updated by the code that has the single write-lock) and you might find the balance is no good (one of the rules fails). This is where the NotEnoughBalanceException comes into play: you promised the "owner" the balance could be updated but now that you have the final write-lock you find the balance cannot be updated (the atomic transaction cannot be completed).
This follows a pretty common pattern: use "cheap" locks to determine if a transaction can be done (perform pre-checks) and then use an "expensive" lock to perform the transaction but always assume the transaction might fail and retry the transaction when appropriate.

Java synchronized methods for a single thread

I'm having trouble understanding the synchronized keyword. As far as I know, it is used to make sure that only one thread can access the synchronized method/block at the same time. Then, is there sometimes a reason to make some methods synchronized if only one thread calls them?

If your program is single threaded, there's no need to synchronize methods.
Another case would be that you write a library and indicate that it's not thread safe. The user would then be responsible for handling possible multi-threading use, but you could write it all without synchronization.

If you are sure your class will be always used under single thread there is no reason to use any synchronized methods. But, the reality is - Java is inherently multi threaded environment. At some point of time somebody will use multiple threads. Therefore whichever class needs thread safety should have adequately synchonized methods/synchronized blocks to avoid problems.

No, you don't need synchronization if there is single thread involved.
Always specify thread-safety policy
Actually you never know how a class written by you is going to be used by others in future. So it is always better to explicitly state your policy. So that if in future someone tries to use it in multi-threaded way then they can be aware of the implications.
And the best place to specify the thread-safety policy is in JavaDocs. Always specify in JavaDocs as to whether the class that you are creating is thread safe or not.

When two or more threads need access to a shared resource, they need some way to ensure that the resource will be used by only one thread at a time.
Synchronized method is used to block the Shared resource between the multiple Threads.
So, No need to apply Synchronization for the Single Thread

Consider that you are designing a movie ticket seller application. And lets drop all the technology capabilities that are provided these days, for the sake of visualizing the problem.
There is only one ticket left for the show with 5 different counters selling tickets. Consider there are 2 people trying to buy the last ticket of the show at the counters.
Consider your application workflow to be such
You take in details of the buyer, his name, and his credit card
number. (this is the read operation)
Then you find out how many tickets are left for the show (this
is again a read operation)
Then you book the ticket with the credit card (this is the write
operation)
If this logic isnt synchronised, what would happen?
The details of Customer 1 and Customer 2 would be read up until step 2. Both will try to book the ticket and both their tickets would be booked.
If it is modified to be
You take in details of the buyer, his name, and his credit card
number. (this is the read operation)
Synchronize(
Then you find out how many tickets are left for the show (this is
again a read operation)
Then you book the ticket with the credit card (this is the write
operation) )
There is no chance of overbooking the show due to a thread race condition.
Now, consider this example where you absolutely know that there will be only and only 1 person booking tickets. There is no need for synchronization.
The ticket seller here would be your single thread in case of your
application
I have tried to put this in a very very simplistic manner. There are frameworks, and constraints which you put on the DB to avoid such a simple scenario. But the intent of the answer is to prove the theory of why thread synchronization, and not the capabilities of the way to avoid it.