Why do i need to add transaction in this?

Question

Why do we need to always Start a transaction in hibernate to save,insert,delete or update?

Is the auto commit feature by default false in hibernate?

like for this

public static void main(String[] args) {
        System.out.println("creating empopbjects");
        emp e1=new emp("a","x",1234);
        emp e2=new emp("b","y",324);
        emp e3=new emp("c","z",23345);
        System.out.println("saving emp objects..");
        Session s=myfactory.getsession();
        s.save(e1);
        s.save(e2);
        s.save(e3);
        s.close();
        System.out.println("successfully saved");
    }

This wont save anything whereas if i add Transaction then only it is added?why so?

public static void main(String[] args) {
        System.out.println("creating empopbjects");
        emp e1=new emp("a","x",1234);
        emp e2=new emp("b","y",324);
        emp e3=new emp("c","z",23345);
        System.out.println("saving emp objects..");
        Session s=myfactory.getsession();
        Transaction t =s.beginTransaction();
        s.save(e1);
        s.save(e2);
        s.save(e3);
        t.commit();
        s.close();
        System.out.println("successfully saved");
    }

Vlad Mihalcea · Answer 1 · 2018-01-05T16:34:20.410

Hibernate Session is a Unit of Work, and queries are only executed during flush time (which may occur prior to executing any query, or when your currently executing Transaction is committed).

Auto-commit is only meaningful in SQL consoles and it's undesirable in Enterprise applications. When using an ORM tool, you are managing Entity object state transitions rather than executing DML operations. It's only at the flush time, when state transitions are translated to DML operations.

So, while you can write JDBC statements in auto-commit, JPA doesn't allow you to do so.

score 2 · Accepted Answer · edited May 23 '17 at 11:43

Well defined answer of your question from one of the SO page is here.

Look at the following code, which accesses the database without transaction boundaries:
Session session = sessionFactory.openSession(); 
session.get(Item.class, 123l); 
session.close(); 
By default, in a Java SE environment with a JDBC configuration, this is what happens if you execute this snippet:

A new Session is opened. It doesn’t obtain a database connection at this point.

The call to get() triggers an SQL SELECT. The Session now obtains a JDBC Connection from the connection pool. Hibernate, by default, immediately turns off the autocommit mode on this connection with setAutoCommit(false). This effectively starts a JDBC transaction!

The SELECT is executed inside this JDBC transaction. The Session is closed, and the connection is returned to the pool and released by Hibernate — Hibernate calls close() on the JDBC Connection. What happens to the uncommitted transaction?

The answer to that question is, “It depends!” The JDBC specification doesn’t say anything about pending transactions when close() is called on a connection. What happens depends on how the vendors implement the specification. With Oracle JDBC drivers, for example, the call to close() commits the transaction! Most other JDBC vendors take the sane route and roll back any pending transaction when the JDBC Connection object is closed and the resource is returned to the pool.

Obviously, this won’t be a problem for the SELECT you’ve executed, but look at this variation:
Session session = getSessionFactory().openSession(); 
Long generatedId = session.save(item); 
session.close(); 
This code results in an INSERT statement, executed inside a transaction that is never committed or rolled back. On Oracle, this piece of code inserts data permanently; in other databases, it may not. (This situation is slightly more complicated: The INSERT is executed only if the identifier generator requires it. For example, an identifier value can be obtained from a sequence without an INSERT. The persistent entity is then queued until flush-time insertion — which never happens in this code. An identity strategy requires an immediate INSERT for the value to be generated.)

Bottom line: use explicit transaction demarcation.

Why do i need to add transaction in this?

2 Answers2