I'm using Hibernate transaction for read operation from db as following excample code:
Session session = sessionFactory.openSession();
Transaction tx= session.beginTransaction();
session.get(Account.class, new Long(id));
tx.commit(); //Actually I use tx.rollback()
session.close();
Due to the second level cache, result is fetched from cache after the first time reading from db. But the database connection is distributed when session.beginTransaction() is invoked, and next commit statement will be executed at database, which degrades the performance dramatically(compared to the case when no transaction is used).
So is there any possible way to know that the result will be read from second level cache so I can avoid doing commit and even use a new database connection?
Assuming you are using spring transaction support, have your tried using SUPPORTS propagation level?
#Transactional(propagation = Propagation.SUPPORTS, readOnly = true)
Can you have multiple transactions within one Hibernate Session?
I'm unclear if this is an allowable desirable. In my code I have a long running thread and takes items from a Blocking Queue, depending on what is on the queue, it may need to create and save a hibernate object, or it may not need to do anything.
Each item is distinct so if item 1 is saved and item 2 fails to save whatever reason I don't want to that to prevent item 1 being added to the database.
So the simplest way to do this is for each item that needs to be created to create a new session, open transaction, save new object, commit transaction, close session
However, that means a new session is created for each item, which seems to go against Hibernates own recommendations to not do Session Per Request Pattern. So my alternative was to create one session in the thread, then just open and commit a new transaction as required when needed to create a new object. But I've seen no examples of this approach and I'm unsure if it actually works.
The session-per-request pattern uses one JDBC connection per session if you run local transactions. For JTA, the connections are aggressively released after each statement only to be reacquired for the next statement.
The Hibernate transaction API delegates the begin/commit/rollback to the JDBC Connection for local transactions and to the associated UserTransaction for JTA. Therefore, you can run multiple transactions on the same Hibernate Session, but there's a catch. Once an exception is thrown you can no longer reuse that Session.
My advice is to divide-and-conquer. Just split all items, construct a Command object for each of those and send them to an ExecutorService#invokeAll. Use the returned List to iterate and call Future#get() to make sure the original thread waits after all batch jobs to complete.
The ExecutorService will make sure you run all Commands concurrently and each Command should use a Service that uses its own #Transaction. Because transactions are thread-bound you will have all batch jobs run in isolation.
Obviously, you can. A hibernate session is more or less a database connection and a cache for database objects. And you can have multiple successive transactions in a single database connection. More, when you use a connection pool, the connection is not closed but is recycled.
Whether you should or not is a matter of reusing objects from session. If there is a good chance but you can reuse objects that a preceding transaction has put in session, you should keep one single session for multiple transactions. But if once an object has been committed, it will never be re-used, it is certainly better to close the session and re-open a new one, or simply clear it.
How to do it :
If you have a Session object, you create transactions with :
Transaction transaction;
transaction = session.beginTransaction();
... (operations in the context of transaction)
transaction.commit();
... (other commands outside of any transaction)
transaction = session.beginTransaction();
... (and so on and so forth ...)
From hibernates documentation
"A Session is an inexpensive, non-threadsafe object that should be used once and then discarded for: a single request, a conversation or a single unit of work. A Session will not obtain a JDBC Connection, or a Datasource, unless it is needed. It will not consume any resources until used."
so if you are creating sessions again and again it will not burden the system much. If you are continuing a session for too long it may create problems as session is not thread safe .In my opinion you simplest solution is the best "So the simplest way to do this is for each item that needs to be created to create a new session, open transaction, save new object, commit transaction, close session"
By the way if you are creating single record of anything you dont need transaction too much. creating single record is inherently " all or none" thing for which we use transaction
package hibernate;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.boot.registry.StandardServiceRegistryBuilder;
class Tester {
public static void main(String[] args) {
SessionFactory sf = new org.hibernate.cfg.Configuration().configure().buildSessionFactory(new StandardServiceRegistryBuilder().configure().build());
Session session = sf.openSession();
session.beginTransaction();
Student student = new Student();
student.setName("Mr X");
student.setRollNo(13090);
session.save(student);
session.getTransaction().commit();
session.getTransaction().begin();
session.load(Student.class,23);
student.setName("New Name");
student.setRollNo(123);
session.update(student);
session.getTransaction().commit();
session.close();
}
}
Short answer is yes, you can use same session for transaction. Take a look at org.hibernate.Transaction., it has required method to manage transaction.
docs.jboss.org Chapter 13. Transactions and Concurrency
Use a single database transaction to serve the clients request, starting and committing it when you open and close the Session. The relationship between the two is one-to-one and this model is a perfect fit for many applications.
It seemed we should always obey the "one-to-one relationship" rule.
But, although the sample below will trigger a exception in the line where the second "session.beginTransaction()" is called
Exception in thread "main" java.lang.IllegalStateException: Session/EntityManager is closed
private static void saveEmployees(SessionFactory factory) {
// crate session
//Session session = factory.openSession();
Session session = factory.getCurrentSession();
{
// start a transaction
Transaction trans = session.beginTransaction();
// create an employee
Employee tempEmployee = new Employee("Steve","Rogers", "The Avengers");
// save to database
session.save(tempEmployee);
// commit the transaction
trans.commit();
}
{
// start a transaction
Transaction trans = session.beginTransaction();
// create an employee
Employee tempEmployee = new Employee("Tony","Stark", "The Avengers");
// save to database
session.save(tempEmployee);
// commit the transaction
trans.commit();
}
// close session
session.close();
}
, another sample below will work properly.
The only difference is that the second sample uses "factory.openSession()" to get a session, instead of "factory.getCurrentSession()".
private static void saveEmployees(SessionFactory factory) {
// crate session
Session session = factory.openSession();
//Session session = factory.getCurrentSession();
{
// start a transaction
Transaction trans = session.beginTransaction();
// create an employee
Employee tempEmployee = new Employee("Steve","Rogers", "The Avengers");
// save to database
session.save(tempEmployee);
// commit the transaction
trans.commit();
}
{
// start a transaction
Transaction trans = session.beginTransaction();
// create an employee
Employee tempEmployee = new Employee("Tony","Stark", "The Avengers");
// save to database
session.save(tempEmployee);
// commit the transaction
trans.commit();
}
// close session
session.close();
}
I am a starter, and I don't know why "factory.getCurrentSession()" works differently from "factory.openSession()", yet.
I am referring to https://developer.jboss.org/wiki/SessionsAndTransactions and currently trying to understand demarcation with JTA. It states that within a particular transaction using getCurrentSession() always gives the same current session. Does it mean:
If another user is executing the same piece of code (which fetches a transaction by lookup, then uses getCurrentSession() and then closes the transaction) in another thread - that user will have his own transaction and his own current session i.e. the current sessions of 2 users are same for themselves but different from each other?
If 1 is true and based on the code shown in the link for JTA demarcation - how does the system (read Hibernate) understand which session to respond to which user when getCurrentSession() is used? After all we don't pass the transaction as argument to getCurrentSession().
Any pointers/help is much appreciated.
Thanks
According to javadoc SessionFactory.getCurrentSession()
The definition of what exactly "current" means controlled by the {#link org.hibernate.context.spi.CurrentSessionContext} impl configured
for use.
JTA is configured this will default to the {#link org.hibernate.context.internal.JTASessionContext} impl.
Then you can see JTASessionContext javadoc and implementation.
If a session is not already associated with the current JTA transaction at the time {#link #currentSession()} is called, a new session will be opened and it will be associated with that JTA transaction.
public Session currentSession() throws HibernateException {
...
final TransactionManager transactionManager = jtaPlatform.retrieveTransactionManager();
...
txn = transactionManager.getTransaction();
...
final Object txnIdentifier = jtaPlatform.getTransactionIdentifier( txn );
...
Session currentSession = currentSessionMap.get( txnIdentifier );
...
}
TransactionManager javadoc
Internally, the transaction manager associates transactions with threads,
and the methods here operate on the transaction associated with the
calling thread.
So, it's similar (but more clearly) to
Sessions and Transactions/Transaction demarcation with plain JDBC:
In other words, the session is bound to the thread behind the scenes, but scoped to a transaction, just like in a JTA environment.
As we all know that in Hibernate if no transaction commit, the changes won't affect in database. But I found something weird. And the code as follows:
ApplicationContext ctx = new ClassPathXmlApplicationContext("Spring.xml");
SessionFactory sessionFactory = (SessionFactory) ctx.getBean("sessionFactory");
Session session = sessionFactory.openSession();
Model model = new Model();
...
session.save(model);
session.flush();
session.close();
And the model was saved to database even there's no transaction, anyone can explain this?
Any comments would be appreciated! Thanks!
PS: I am using mysql.
The session.flush command saved the transaction. If it's wrong, you should use transaction.
usually hibernate needs the line session.beginTransaction(); to work. You didn't write that and your application worked, I guess your application runs in an Application server, which provides transaction management. e.g. jboss, weblogic...
However it doesn't mean that there is no transaction. Did you set auto-commit true?
btw, session.flush() and txn.commit() are different.
Flushing is the process of synchronizing the underlying persistent store with persistable state held in memory.
After session.flush(), you still can call txn.rollback() to rollback all changes.
edit
oh I saw you used spring. did you configured txnmanager in spring?
Hibernate doesn't need transactions, the most common problems in database-based applications are just easier to solve with transactions which is why usually everyone uses transactions with Hibernate. But that's mere coincidence/convention/laziness.
All Hibernate needs is a java.sql.Connection and if your container provides one even though there is no current transaction manager configured, Hibernate is fine with that.
In fact, Hibernate has no idea that there might be a transaction manager. So session.flush() will use the ApplicationContext to get a connection, generate the SQL and use JDBC to send the generated SQL code to the database.
From Hibernate's point of view, that's all that happens.
There can be several reasons why the data is committed to the database:
You forgot to turn of auto commit on the connection.
Your web container / spring config automatically wires a transaction manager that synchronizes with HTTP requests.
Your code is called form another method which is annotated with #Transactional; in this case, you inherit the existing transaction.
I have a little of confusion about JDBC connection, transactions and their integration in EJB, JTA, Hibernate environment. My doubts are:
when we use #Resource DataSource ds; ... ds.getConnection() , are we working in the same transaction used by the managed bean? Should we close the connection, statement, resultset?
what about session.doWork? Are we in the same transaction? What about closing statement and result set?
aggressive release mode in Hibernate means that connections are closed after each statement. Does it mean that transaction is committed too? (I don't think this is true, but I can't understand how Hibernate works here)
There are a few things you need to figure out. First thing you need to identify what is your unit of work.
The session-per-request pattern is one of the most used and unless you have specific needs stick with that.
If you are using Hibernate you don't use statements and result sets directly. Hibernate will do that for you. what you need to close is the hibernate session
What you use is a SessionFactory and a Session object. The session pretty much represents your unit of work. Inside the hibernate session you get your objects, you change them and save them back.
The session per request pattern opens a session when a request is received and closes it when the response is sent back.
In a container managed EJB session bean a transaction is available and the datasource you (or hibernate) use in such a container is automatically handled by a JTA TransactionManager.
Now because Hibernate is smart it can automatically bind the "current" Session to the current JTA transaction.
This enables an easy implementation of the session-per-request strategy with the getCurrentSession() method on your SessionFactory:
try {
UserTransaction tx = (UserTransaction)new InitialContext()
.lookup("java:comp/UserTransaction");
tx.begin();
// Do some work
factory.getCurrentSession().load(...);
factory.getCurrentSession().persist(...);
tx.commit();
}
catch (RuntimeException e) {
tx.rollback();
throw e; // or display error message
}
So to answer your questions:
If you are using Hibernate with JTA in a container you'd be better off using a JPA EntityManager or maybe spring hibernate template.
Here are some references:
http://community.jboss.org/wiki/sessionsandtransactions#Transaction_demarcation_with_JTA
http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/orm/hibernate3/HibernateTemplate.html