Logical Unit of Work and Single Unit of work in JPA, JTA

Question

I often came across these terms. Is their a difference b/w the 2 of them?

In the following piece of Java code, the method is thread-safe:

class Counter {
    private int i = 0;

    public synchronized void inc() {
        i++;
    }
}

In context to SessionFactory and Session in Hibernate then,

SessionFactory (org.hibernate.SessionFactory) - A thread-safe

Session (org.hibernate.Session) - A single-threaded, short-lived object representing a   
conversation between the application and the persistent store. 

I get confused here in understanding their definition.

All i absorb is that since SessionFactory is thread-safe, any thread first needs to acquire a lock and then would be working on it, i.e Implementation is guaranteed to be free of race conditions when accessed by multiple threads simultaneously. (Notice i wrote simultaneously and not parellely). After one thread has finished its work, another one in queue would be acquiring the lock then and so on. No 2 threads will be working on it exactly at the same time.

Session is not thread safe, and it represents a single-threaded unit of work.

Is it that after a sessionfactory, multiple sessions (in a sessionfactory) will be evolving each span their own work in their own single-thread?

Answer 1

A SessionFactory is thread-safe and you have a singleton Sessionfactory for a given DataSource.

The Sessions can either be created for the life time of a single request or even extended to span over multiple user requests.

The Session has always have to be bound to a single Thread at any given time. Even when you use an extended persistence context, it's only one request/thread to access the Session at a point-in-time.

So the Session should not be accessed concurrently. That's why you don't need to synchronize your entities, at least not from Hibernate point of view. Each Session loads it's own copy of an entity and the concurrency is usually ensured with optimistic locking because it's desirable to have application-level repeatable reads.

So entities should not be synchronized. The concurrency control happens inside the database, not in your application logic. Each client request will always issue DML statements in the scope of a physical database transaction, and database transactions always acquire locks when rows get changes (even for READ_COMMITTED).

All in all, the Session is not tread-safe along with all its attached Entities. The Session factory is thread-safe because you get only one singleton instance per DataSource and you use it to create new Sessions.