Hi,
I have a web application. I am using a Seam Managed Entity Manager and have set the flush mode to manual. I am using hibernate as my JPA implementation.The idea is over a web conversation, several entityManager operations are performed but the EntityManager only flushes to the database at the end of the web conversation.

I am just wondering when hibernate actually decides to get a database connection:
1. As soon as an EntityManager is instantiated?
2. As soon as any EntityManager is performed?
3. Only when the EntityManager actually flushes to the database?

The reason why I need to know is because I need to know how my application will scale. I need to know how long a connection is in use, before I configure connection pools appropriately.

Many many thanks.

Option 1 and 3 are not technically feasible so they are out. As for option 2, this really depends what transaction management you are using. JDBC transaction strategy will require a connection as soon as a transaction starts. I do believe CRUD methods also require a connection, which is injected into method parameters down in hibernate class hierarchy from a ConnectionManager. In any events, it is a bad practice to keep your database session open for a conversation scope unless you are sure about your app's db locks and you have fairly a low number of users.


Farzad-

Why is option 3 technically out?
If I don't do anything with the database, why should I need a connection?
BTW I am using JTA here.

You lost me here. If you don't do anything with database then why would you need an entity manager?


Farzad-

Seam makes the decision when the EntityManager is created etc as I am using a SeamManaged EntityManger. However the implement of the EntityManager is Hibernate, so I thought someone would know when Hibernate decides when the connection is first used or created.

Are you using Seam's web conversations? To tell you the truth I am not aware how Seam handles this but you might get an answer by monitoring your connection pool. As far as I understand database transaction works as a whole so if you even start accessing data at the beginning of a conversation the underlying jdbc connection needs to hold to db locks as specified by transaction isolation and it does not matter where in conversation you make changes, you will still need to be in the scope of the same transaction. I have a feeling Seam stores transaction information in a web session scope and then it decides to commit at the end of a conversation. however, I am just shooting in the dark and you would get a better answer from Gavin himself. I am not sure if he still monitors hibernate forums but you may want to post this question on the Seam forum too.



Farzad-

Hi,
I have posted this issue on the Seam forum who basically stated it was up to the JPA vendor when the connection is used.

See this link:
http://www.jboss.com/index.html?module= ... 00#4117100

Any info would be great.
Thanks

Hibernate does release the connection as soon as it has done a statement in a JTA transaction and with a connection pool.

Thanks emmanuel, when does actually hibernate get a connection, lets say in a JTA environment and with a connection pool? Before running a statement? In the case a session is shared between multiple threads, does hibernate hold the connection? Does in a JTA environment hibernate become totally transaction agnostic (except for the L2 Cache update callbacks)?


Farzad-

Thanks for that. I would just like to know when does Hibernate first get a connection. For example
1. As soon as an EntityManager is used?
2. Only when it needs to do i.e. when it is about to flush to the DB.

Also is there any difference between different enviroments (JTA Transaction, non JTA transaction)?
Thanks a million.

any update on this?
Thanks

Hibernate get the connection only when it needs it, so as late as possible. And release it as soon as possible.
Depending on the transactional environment, as late as possible and as soon as possible differ (JDBC is less aggressive than JTA). It also depends if your connectionProvider supports what is called aggressive release. For more go and check the code :)

Oh and you must not share the same session across different threads, that is bad.

Thanks, just so I understand when you say JTA is more aggresive, does this mean in JTA is the connection sought sooner and held for longer?

no the other way around, hibernate keeps the connection for a shorter amount of time.

sorry, perhaps I was unclear.
Which keeps the connection for a shorter amount of time?
Hibernate using JTA
or
Hibernate not using JTA

PS I was looking through the code and what would be really useful if there was logging in this area. If there was, I could turn on the logging and get a clearer view what happens runtime. I am using an AppServer so setting up a debugger is non trivial.