Hibernate获取而无需显式事务

Question

I am trying to understand the reason behind using transaction in the following piece of code retrieved from Hibernate Documentation.

Session session1 = factory1.openSession();
Transaction tx1 = session1.beginTransaction();
Cat cat = session1.get(Cat.class, catId);
tx1.commit();
session1.close();
//reconcile with a second database
Session session2 = factory2.openSession();
Transaction tx2 = session2.beginTransaction();
session2.replicate(cat, ReplicationMode.LATEST_VERSION);
tx2.commit();
session2.close();

What I understand from this JBOSS Wiki that even though if I dont use a transaction that should not be a problem in this case. Can some body educate me more on this in terms of isolation etc . what actually happens if we do or dont use transaction in the above scenario

Working nontransactionally with Hibernate 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: 1. A new Session is opened. It doesn't obtain a database connection at this point. 2. 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! 3. 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:

Answer 1

If its one statement you wouldnt tell the difference, but if you are trying to do multiple statements in a single transaction you would see what they are for.

If you open a transaction and attempt multiple CRUD operations and one fails, you can roll back the transaction and pretty much go back to a previous state within the transaction (even before everything).

On the other hand, if you dont open a transaction, its opened and closed implicitly every time you use a statement so if you do multiple CRUD operations and one fails, there is no way to roll back the data and you will end up with bad data.

Side note : this doesnt really matter for select statements