How Do Synchronized Static Methods Work in Java and How to Use It for Loading Hibernate Entities

How do synchronized static methods work in Java and can I use it for loading Hibernate entities?

By using synchronized on a static method lock you will synchronize the class methods and attributes ( as opposed to instance methods and attributes )

So your assumption is correct.

I am wondering if making the method synchronized is the right approach to ensure thread-safety.

Not really. You should let your RDBMS do that work instead. They are good at this kind of stuff.

The only thing you will get by synchronizing the access to the database is to make your application terribly slow. Further more, in the code you posted you're building a Session Factory each time, that way, your application will spend more time accessing the DB than performing the actual job.

Imagine the following scenario:

Client A and B attempt to insert different information into record X of table T.

With your approach the only thing you're getting is to make sure one is called after the other, when this would happen anyway in the DB, because the RDBMS will prevent them from inserting half information from A and half from B at the same time. The result will be the same but only 5 times ( or more ) slower.

Probably it could be better to take a look at the "Transactions and Concurrency" chapter in the Hibernate documentation. Most of the times the problems you're trying to solve, have been solved already and a much better way.

What does synchronized on a static method do?

Yes, the class "gets" the lock instead of the instance (as Bruno pointed out, this terminology is imprecise. The Thread gets the lock using either the class object or the instance as the locking object). Meaning, you could have 3 threads simultaneously executing 3 synchronized methods if those methods are synchronized on their individual instances. If the method is synchronized on the class, then only one thread can be executing it.

How java synchronized work

If class A has two synchronized methods, say, methodA and methodB. If one thread is accessing methodA, can another thread access methodB? According to my understanding, when accessing methodA, the thread get lock of the object, the other thread shouldn't be able to access methodB at the same time.

That's right; if one thread holds the lock to the object, other threads have to wait before they can get the lock. Ofcourse this is only the case if both threads are calling methods on the exact same object.

But this will downgrade the performance a lot, right?

It might affect performance, but sometimes it's necessary, for example to prevent two threads from modifying the same data concurrently.

And, I seemed used to read one article that says the other thread can access methodB. Which one is correct?

The first is correct, the second is incorrect.

Java synchronize behaviour for static and non-static method

I think it can be explained simpler

1) when a thread has entered a synchronized instance method then no other thread can enter any of synchronized instance methods of the same instance

2) when a thread entered a synchronized static method then no other thread can enter any of synchronized static methods of the same class

Java synchronized static methods: lock on object or class

Since a static method has no associated object, will the synchronized keyword lock on the class, instead of the object?

Yes. :)

Static syncronized method and non-static synchronized method can both work on static member variables and this can cause unexpected behaviour

Why do the Java creators didn't take this into account?

They did, and thats why you have option to sync on a class and object levels.

What can be the right way of dealing with this type of situation?

You must use synchronized(Demo.class) {...} in your get() method.

Can synchronized methods serve all purposes which a synchronized block can?

A synchronized method is nothing but syntactic sugar for synchronized(this) {...}.

So the literal answer to your question is "not easily". You would need two different objects where the two synchronized methods are declared, and call one from the other. But it seems like a bad idea.

In general, I question the goal of trying to reduce an explicit synchronized block to a synchronized method. Synchronized blocks are more readable, and let you encapsulate the lock object to prevent undesired lock contention if some other code decides to use the same instance as the lock for some reason.

Also, are you sure you need the kind of fine-grained locking you're trying to do? This seems error-prone... a more straightforward code would synchronize on the same object for any operation on the list.