Hi,

What is the intent of Session Object and Transaction. Is there a good documentation for clearly explaing the intent of these two.

You could read one of the following books:

Hibenate in action
Java persistence using hibernate


A session is a collection of loaded objects relating to a unit of work. For every unit of work you will need a session instance. Hibernate can detect changes made to the objects within a session.

A transaction interface on the other hand provides method to specify the boundaries of a database transaction (start and end of a transaction). Hibenate Transaction interface is an optional interface and the you can choose to write your own transaction management code instead of using the Hibernate Transaction API.

Hi,

Looking into one the book you mentioned

http://www.scribd.com/doc/261016/Java-P ... -Hibernate

page No 47 i.e Physical No: 82.

Based on your summary and what is given in the book.. I am still not very clear with the following

1. In the entire application, could I have only one session and mutiple transactions.

2. If one session is related to only one transaction (Most of the books seems to say this..), then why not just have one..

Why the persistance of objects such as save, update etc were not static methods..

Regards,
Nagendra

Usually in any application, you will not have a single session. You open and close sessions as and when required. You open a session everytime you need to perform a database operation and close it after your unit of work is over. A session may have multiple transactions. But at a time it is prefered to have atleast one uncommitted transaction within a session.

You can see transaction API documentation for more details:
http://www.hibernate.org/hib_docs/v3/api/org/hibernate/Transaction.html

> Usually in any application, you will not have a single session.

Any reason why we should not design the one session for the application i.e in similar lines to web applications session.

i.e I will only have one session and each unit of work would be part transaction. I am unable to clearly identify the need for session still if I were to associate multiple sessions per unit of work.

> But at a time it is prefered to have atleast one uncommitted transaction within a session.

Any reason why such recommendation..

Regards,
Nagendra

The idea of session is to seperate work units. However if you plan to create a session and do all your persistence having just multiple transactions, you can very well do it but it would not be a great design. Sessions are not threadsafe. And with a single session for the whole application, threadsafety becomes all the more difficult. It would do nothing more than complicate things.


I suggest you do not think of web application session when dealing with hibernate session. Hibernate sessions are in no way related to http sessions and its better not to compare these to entirely different things

You can also go through this document for more info on session and transaction
http://www.hibernate.org/42.html#A2

Every time you want to work with any Database, you need to obtain a connection. In Hibernate you configure the DB properties in the .properties OR .xml file.

Whenever you create a Session, internally a DB Connection object is created and till you close the session, the connection would be open.

Now if the application is multiuser and the DB Connections would be used on above basis i.e. each user opens the connection in there own requests and never close it, than you would be short of DB Connections. And you know the consequences if there are no Connections to DB.

On the other hand, Transation is something for us to describe what is the Unit of Work that we want. For ex...lets says

For ex...lets say...I have a Unit of Work defined for Shopping App.

After user enters the Credit Card Info ----- verify the card info , deduct the amount from his account -----put the amount into the merchant account ---- update the inventory ----- send a mail or message to the User about the same.

Now, I can make use of session to update the DB but to do other tasks, I need to make use of Transaction..so that they become as one unit of work....either all tasks should happen OR nothing should happen.

I hope you would be clear with this. Let me know if you have any concerns.

Sukirtha,

> Sessions are not threadsafe

if I use Single session or multiple sessions, the issue of thread safety remains..(as this is to deal with the reference beeing used by multiple threads)

Also, when you say more about thread safety, I am not sure what data is in session. Specially, as programmer, I don't store any thing directly in the session, other than calling few methods. However I am not sure what kind of data exists in session by default, which needs to be thread safe..

>http://www.hibernate.org/42.html#A2

Thank you for this link, this seems to have the answer.. however need to understand each line better as the session and transaction seems to have very thin line of difference..

Regards,
Nagendra

>Now if the application is multiuser and the DB Connections would be >used on above basis i.e. each user opens the connection in there own >requests and never close it, than you would be short of DB Connections. >And you know the consequences if there are no Connections to DB.

I am thinking that connections are multiplexed.. meaning with single connection one could excute mutiple statements. This way having single session seems to be better..

Yes, if all the connections are not released, then it could be a big issue. However, my intention is use single session and let session manage the connection managment and release.. As a programmer, I don't want to work on connection level, instead I would only say some query to be executed and transaction to be opened and commited etc.

I am hoping to more on session and its scope other than mapping this to just to connection holder..

Regards,
Nagendra

You seem to be getting confused with Session of Servlet and Session of Hibernate :)

If you can provide the exact problem you are facing, probably I can provide you with a good answer that would satisfy you.

Exactly, A programmer need not necessarily open as session and close. Instead your application framework can handle this part. It all has to be designed such that the programmer doesn't really open or close connection. Let your application framework handle this.



I guess here you are again confusing hibernate session with your HttpSession. The programmer need not store anything in session directly. Every time you trigger a query, the retrieved objects are automatically stored in the hibernate session. IF you don't close the session at all, all the objects you ever retrieved will remain in the session.


As waswani said, if you can really quote the exact problem you are facing, we will be able to help you better.

>I guess here you are again confusing hibernate session with your >HttpSession. The programmer need not store anything in session >directly. Every time you trigger a query, the retrieved objects are >automatically stored in the hibernate session.

Why shoud this happen and what is the purpose of thse objects.. specially when I say there is no cache provider or so in hibernate.cfg.xml..

Regards,
Nagendra

Its like this:
Whenever a query is triggered, the data from the underlying database is populated into your java objects mapped to the corresponding table. These objects are automatically stored in the current session under which you are operating. Session is just hibernates way of storing objects retrieved from database and also storing persistent objects to be stored in database. The retrieved objects need to be stored in some place to be accessible by the application right? and that some place is the hibernate session. You can read the objects from the session and choose to close the session when needed. Its generally a good practise to close the session as soon as you are done with reading/saving the data or more clearly - as soon as you complete your work unit.

>Its generally a good practise to close the session as soon as you are done with reading/saving the data or more clearly - as soon as you complete your work unit..

Sukirtha, I am more convinced that session should be having static methods rather than object methods.. as you also say, it has to be discarded as soon as the unit of work is done.

I also assume that session and cache are different so even if hibernate internally would like to store and optimise the execution time, it could depent on cache instead of queiry..

Take the case of session trying to retrive object, once the object is retrived and its reference is passed to the caller, session need not maintance any details about that query or that object... If some thing to be done for per reason, it should be handeled by cache and on session.



Regards,

Session object behaves as a primary cache. Lets take it this way...you retrive a object from a database. This object has around 50 fields. And u do update on only 1 field due to some reason.

Now as per your understanding. when u update the object using the hiberbnate framework, hibernate has to update all the 50 fields because he has got no idea which field u changed.

This would not be the good idea. Even EJB2.0 also had the same problem. It was improved in EJB2.1 version.

Hiberbnate Session also caches the object and would know which field got changed and would update the only field which got changed and not the others 49 when you say update the object.


Also, how do u say session class should have static methods. You got to create session object and close them for DB interaction. You don;t have only only one object of session per application. May be your application has this approcah of having one Session object (which again depends on the scale and architecture of the application)...but the generic DB rule is create the connection when required and close it as soon as possible. So it makes sense to have Session having object methods and not static methods. If you want to make use of these methods as static, make use of Singelton Pattern and get the job done.