How to know if a method is thread safe

Question

Suppose I have a method that checks for a id in the db and if the id doesn't exit then inserts a value with that id. How do I know if this is thread safe and how do I ensure that its thread safe. Are there any general rules that I can use to ensure that it doesn't contain race conditions and is generally thread safe.

public TestEntity save(TestEntity entity) {
       if (entity.getId() == null) {
            entity.setId(UUID.randomUUID().toString());
        }
        Map<String, TestEntity > map = dbConnection.getMap(DB_NAME);
        map.put(entity.getId(), entity);
        return map.get(entity.getId());
}

Answer 1

This is a how long is a piece of string question...

A method will be thread safe if it uses the synchronized keyword in its declaration.

However, even if your setId and getId methods used synchronized keyword, your process of setting the id (if it has not been previously initialized) above is not. .. but even then there is an "it depends" aspect to the question. If it is impossible for two threads to ever get the same object with an uninitialised id then you are thread safe because you would never be attempting to concurrently modifying the id.

It is entirely possible, given the code in your question, that there could be two calls to the thread safe getid at the same time for the same object. One by one they get the return value (null) and immediately get pre-empted to let the other thread run. This means both will then run the thread safe setId method - again one by one.

You could declare the whole save method as synchronized, but if you do that the entire method will be single threaded which defeats the purpose of using threads in the first place. You tend to want to minimize the synchronized code to the bare minimum to maximize concurrency.

You could also put a synchronized block around the critical if statement and minimise the single threaded part of the processing, but then you would also need to be careful if there were other parts of the code that might also set the Id if it wasn't previously initialized.

Another possibility which has various pros and cons is to put the initialization of the Id into the get method and make that method synchronized, or simply assign the Id when the object is created in the constructor.

I hope this helps...

Edit... The above talks about java language features. A few people mentioned facilities in the java class libraries (e.g. java.util.concurrent) which also provide support for concurrency. So that is a good add on, but there are also whole packages which address the concurrency and other related parallel programming paradigms (e.g. parallelism) in various ways.

To complete the list I would add tools such as Akka and Cats-effect (concurrency) and more.

Not to mention the books and courses devoted to the subject.

I just reread your question and noted that you are asking about databases. Again the answer is it depends. Rdbms' usually let you do this type of operation with record locks usually in a transaction. Some (like teradata) use special clauses such as locking row for write select * from some table where pi_cols = 'somevalues' which locks the rowhash to you until you update it or certain other conditions. This is known as pessimistic locking.

Others (notebly nosql) have optimistic locking. This is when you read the record (like you are implying with getid) there is no opportunity to lock the record. Then you do a conditional update. The conditional update is sort of like this: write the id as x provided that when you try to do so the Id is still null (or whatever the value was when you checked). These types of operations are usually down through an API.

You can also do optimistics locking in an RDBMs as follows: SQL Update tbl Set x = 'some value', Last_update_timestamp = current_timestamp() Where x = bull AND last_update_timestamp = 'same value as when I last checked' In this example the second part of the where clause is the critical bit which basically says "only update the record if no one else did and I trust that everyone else will update the last update to when they do". The "trust" bit can sometimes be replaced by triggers.

These types of database operations (if available) are guaranteed by the database engine to be "thread safe".

Which loops me back to the "how long is a piece of string" observation at the beginning of this answer...