[hibernate-dev] hibernate and transaction using method annotation

Bhuvan Gupta bhuvangu at gmail.com
Fri Apr 29 00:10:46 EDT 2016


Hello All,

Link to question and discussion:

http://stackoverflow.com/questions/36920695/hibernate-and-transaction-using-method-annotation

Below i have pasted whats in the link:

Help/suggestion/advise/data points is really appreciated.

Thanks in Advance:

------------------------------------------

Firstly, I have given few data points.
Next will be the problem described.
------------------------------

*DATA POINTS:*
*[D1]* In Hibernate and Annotation and managed objects world, what i have
seen a common pattern like

@Transactionalpublic void createStuff(..){// get entity manager and
call persist and other operatation}@Transactionalpublic SomeDtoObject
getStuff(..){// get entity manager and call find and getter to
polulate a object to return}

In managed beans the Hibernate transaction is started and commited when we
call this methods.

Hibernate doc says (link
<https://docs.jboss.org/hibernate/orm/3.5/reference/en/html/transactions.html>
):

The most common pattern in a multi-user client/server application is
session-per-request.

*[D2]* Also it is advised that connection to database should be pooled
using connection pool library C3P0 as stated on postgres documentation (link
<https://jdbc.postgresql.org/documentation/91/thread.html>):

Pg will usually complete the same 10,000 transactions faster by doing them
5, 10 or 20 at a time than by doing them 500 at a time.

*[D3]* Also with JDBC

*Given a single connection we can run one transaction at a time and as many
statement as we like within that transaction.Its upto the application(C3P0)
to make sure that two different thread executing two different
transactional method should not use same connection and one should wait
before calling the other method .*
------------------------------

*Problem:*
Now if we use the managed bean transaction pattern using annotation along
with a connection pool(*Let say only with 1 connection*) with hibernate and
session-per-request
Also let say the code is something like

@Transactionalpublic SomeDtoObject getStuff(..){// get entity manager
and call find and getter to polulate a object to returnSomeEntity se =
entityManager.find(someentity, primaryKey);//create Dtos// access
someEntity to all over this method to create SomeDtoObject that we
have to return.// also may access some file on system to fetch some
data is order to populate someDtoObject.// overall let say the method
take 150 milli second to do all its work}

Now imagine there are two different thread(T1, T2) called for getStuff(...)
T1 will enter the method and will acquire jdbc connection from connection
pool.
And when T2 will reach entityManager.find the C3P0 will check that there is
no connection left it will put T2 on hold till T1 complete the execution
which will take around 150 milli second.

Ideally, Given that getStuff(...) is going to do read only querys, both
thread can use same connection and dont hold thread from executing queries.
In above case we are keep that connection idle and also keeping the thread
to wait.

*MAIN QUESTION*
*Is there a way i can say to hibernate that a particular hibernate
transaction is readonly and hibernate can then reuse an already acquired
connection instead of asking for a new connection from the connection pool
?*
------------------------------

*Few solution found/suggested:(not convincing)*

1
<https://docs.jboss.org/hibernate/orm/3.5/reference/en/html/transactions.html>
If
you are so much worried, dont use transaction using annotation, use
hibernate session yourself..... no i like that pattern :)
2 <https://jdbc.postgresql.org/documentation/91/thread.html> Hibernate
provide a ConnectionReleaselink
<https://docs.jboss.org/hibernate/orm/3.5/reference/en/html/transactions.html#transactions-connection-release>
option
which can be set to after_statement.
*First* Hibernate C3P0 connection pool provider does not support
after_statement.
*Second* it will be a overhead just release and reacquire a connection.


More information about the hibernate-dev mailing list