The idea of persistence in hibernate!

[shaji]

Hi:

I had earlier posted a question regarding 'how persistence achieved
using hibernate'. Probably my idea of persistence might be wrong! I
hope some of you will help me out.

Is it possible to use a single session for several database
transanctions with disconnections between each request(from browser).

So are we carrying the session details across the network? (This
will increase the payload and effect the
performance, right?)

Otherwise how sessions are restored across http-sessions?


Now, I think of Hibernate as a way to map an object to a database.

you have a table:

table TEST {
ID int,
NAME varchar2(50),
....

}

You could have a class:

class Test {
private int id;
private String name;
....

}


Hibernate will persist the data to table TEST, it will generate the
SQL required to create/update/retrieve the data, and instead of using
JDBC calls, you just call Hibernate functions. (These statements I am
recalling from another thread appeared here).


We know that, database calls are costly operations mainly due to
connection overheads in establishing JDBC conn. Hibernate also pays
this cost each time it tries to connect to database.

Suppose we created one persistent class of Test in one session. We uses
it. Now the response went back to browser and another request comes in.

Is the class Test created last time still persistent?
Or hibernate obtains a new instance of Test by invoking all those JDBC
conn procedures again?
If it is the second case, what is actually persistence. Everytime you
need the object, you have to contact database. So where is the gain?


Any help will be deeply apprecitated.
-Shaji.

 

[Raymond DeCampo]

Suppose we created one persistent class of Test in one session. We uses
it. Now the response went back to browser and another request comes in.

Is the class Test created last time still persistent?
Or hibernate obtains a new instance of Test by invoking all those JDBC
conn procedures again?
If it is the second case, what is actually persistence. Everytime you
need the object, you have to contact database. So where is the gain?

The gain is that the O/R mapping (object-relational) is done for you.
Adding more tables or more columns requires only changes to your POJOs
and configuration. Otherwise you would need to generate all the SQL
yourself.

As to your concern about the cost of database connections, you should
look into using a connection pool. Apache provides one under the DBCP
project. If you are executing in a J2EE application server, they
provide connection pooling as well.

HTH,
Ray

 

[Bryce]

Hi:

Is it possible to use a single session for several database
transanctions with disconnections between each request(from browser).

So are we carrying the session details across the network? (This
will increase the payload and effect the
performance, right?)

Otherwise how sessions are restored across http-sessions?


Now, I think of Hibernate as a way to map an object to a database.

you have a table:
[snip]

Hibernate will persist the data to table TEST, it will generate the
SQL required to create/update/retrieve the data, and instead of using
JDBC calls, you just call Hibernate functions. (These statements I am
recalling from another thread appeared here).

Good so far.

We know that, database calls are costly operations mainly due to
connection overheads in establishing JDBC conn. Hibernate also pays
this cost each time it tries to connect to database.

To some extent. You will want to setup a connection pool. Also,
Hibernate can cache some data, so it doesn't need to connect to the
database to retrieve it.

Suppose we created one persistent class of Test in one session. We uses
it. Now the response went back to browser and another request comes in.

Is the class Test created last time still persistent?

If you saved it. It Hibernate won't persist it until you do.

Or hibernate obtains a new instance of Test by invoking all those JDBC
conn procedures again?

See above about cacheing.

If it is the second case, what is actually persistence. Everytime you
need the object, you have to contact database. So where is the gain?

Hibernate isn't typically about performance gain, but about ease of
database programming. Now, by using Hibernate, you may get some
performance gains as it tends to do some optimizations. The gain is
being able to use standard java objects, and have the persistence
mechanism work in the background... Most of the gritty details are
transparent to the programmer.

 

[jAnO!]

Otherwise how sessions are restored across http-sessions?

you probably mean how sessions are restored across http-requests.

The container takes care of that, it's in the J2EE spec, container will set
a cookie JSESSIONID or will use URL rewriting (wich you will explicitly have
to do in your code) to identify the session.

 

[=?iso-8859-1?q?Markus_B._Kr=FCger?=]

Is it possible to use a single session for several database
transanctions with disconnections between each request(from browser).

So are we carrying the session details across the network? (This
will increase the payload and effect the performance, right?)

Otherwise how sessions are restored across http-sessions?

If you want to reuse the same Hibernate session, you could store it in
the HttpSession for the current request. The Hibernate session
details are not transmitted across the network, only the HTTP session
identifier, so the network payload should not increase significantly.
This approach is discussed in section 12.3.2. of the documentation:

http://www.hibernate.org/hib_docs/v...ions.html#transactions-optimistic-longsession

We know that, database calls are costly operations mainly due to
connection overheads in establishing JDBC conn. Hibernate also pays
this cost each time it tries to connect to database.

Which is why you want to configure Hibernate to use connection
pooling. This is described in section 4.3 of the documentation:

http://www.hibernate.org/hib_docs/v...onfiguration.html#configuration-hibernatejdbc

Suppose we created one persistent class of Test in one session. We
uses it. Now the response went back to browser and another request
comes in.

Is the class Test created last time still persistent?
Or hibernate obtains a new instance of Test by invoking all those JDBC
conn procedures again?
If it is the second case, what is actually persistence. Everytime you
need the object, you have to contact database. So where is the gain?

Different strategies for handling long-running transactions in
Hibernate is discussed in chapter 12.3 of the Hibernate documentation:

http://www.hibernate.org/hib_docs/v3/reference/en/html/transactions.html#transactions-optimistic

You can choose between keeping the same Hibernate session across HTTP
requests, or detaching the persistent object and reattaching it to a
new Hibernate session during the next HTTP request. In any case,
Hibernate will not contact the database every time you access the
object, only when Hibernate synchronizes persistent objects with the
database (referred to in the documentation as "flushing the session").

Hope this helps!