This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Object Relational Mapping and the fly likes Hibernate: Session and Transaction Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "Hibernate: Session and Transaction" Watch "Hibernate: Session and Transaction" New topic
Author

Hibernate: Session and Transaction

miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
this post continues this conversation.

here's what i got from Hibernate API:

A transaction is associated with a Session and is usually instantiated by a call to Session.beginTransaction(). A single session might span multiple transactions since the notion of a session (a conversation between the application and the datastore) is of coarser granularity than the notion of a transaction. However, it is intended that there be at most one uncommitted Transaction associated with a particular Session at any time.


so now i dont need to declare throws InfrastructureException and/or HibernatException

Notice i never use:

and also use a overall Session, created at top of class: am i playing with fire? (my app is a standalone desktop for crud use - only one single user ever)

One pratcal advantage i get from this aproach is that i dont need anymore to worry about re-opening a session everytime i use one.

this other aproach (the correct one?):

forces me to pay very carefull atention to the existence of sessions in my code - see this example:

[ March 26, 2005: Message edited by: miguel lisboa ]

java amateur
miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
i just read this in hibernate API:

If the Session throws an exception, the transaction must be rolled back and the session discarded. The internal state of the Session might not be consistent with the database after the exception occurs. <hr></blockquote>
do i get back to (moderate) try catch?
my answer is yes, in view of the need of the roll back.

do you agree?
[ March 26, 2005: Message edited by: miguel lisboa ]
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
Originally posted by miguel lisboa:
do i get back to (moderate) try catch?
my answer is yes, in view of the need of the roll back.

do you agree?
Yes, to be make your application robust in the face of failures, you should be doing this. Ninety-nine times out of a hundred, it won't matter. But problems do occur, even in a single-user desktop application.

Sessions are designed to be lightweight and quick to create, thus the use of the SessionFactory which maintains the configuration. You will be fine creating one for each transaction with your application.

However, you don't normally want your DAO managing the transactions or session. This should be left to the business logic. If you are going to change a user's email address, for example. You want to
  • begin a transaction
  • find and load the user
  • set the new email address
  • save the user
  • flush the session
  • commit the transaction

  • This is another place Spring helps out. It provides classes to maintain thread-bound sessions and transactions. When a session is needed, if the thread doesn't have one already, a new one is opened and bound to the thread.

    This is important because the session maintains the unit of work to flush to the database. If you load it in one session and then save it in a different session, you'll have to use saveOrUpdateCopy() so it can reload the user to tell which objects and values have changed.

    For managing the transactions, Spring provides EJB-like method-level transaction demarcation. Spring will begin and commit/rollback transactions based on each method's transaction property.
    David Harkness
    Ranch Hand

    Joined: Aug 07, 2003
    Posts: 1646
    Also, I had a recommendation for your DAO class. First, what does the "dao" instance variable do? I don't see it being used -- though there is a setter.

    Anyway, since all the methods are typed against Object instead of the domain object's interface, Convencao, you could create a base class that would supply 90% of the methods for all of your DAOs.

    Pull the different pieces out of each DAO and make them constructor arguments: domain class and domain class's name. Then all the other methods you have can move to the base class.If you go with the method suggested in the Hibernate documentation, using a common base class will save you tons of cut-n-paste code. As well, if you need to change it in the future, it's all in one place.
    miguel lisboa
    Ranch Hand

    Joined: Feb 08, 2004
    Posts: 1281
    First, what does the "dao" instance variable do? I don't see it being used -- though there is a setter.
    that setter exists because of some mocks i was working on

    BaseDao looks really great!

    I made a quick search in hibenate docs but wanst unable to find the BaseDao reference you mentioned; can you pls tell me where i can find
    it?
    David Harkness
    Ranch Hand

    Joined: Aug 07, 2003
    Posts: 1646
    Originally posted by miguel lisboa:
    BaseDao looks really great!

    I made a quick search in hibenate docs but wanst unable to find the BaseDao reference you mentioned; can you pls tell me where i can find
    it?
    Thanks! I wrote it using your ConvencaoDao as a starter for you. The BaseDao I wrote for my work is based off the same idea, but it uses Spring's HibernateTemplate and wouldn't be very helpful. The main concept, though, is very applicable: create a base class that will handle 90% of the work.

    The only things each domain class DAO I have to write has are the constructor call to pass in the class and its name and any search methods specific to that object.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Hibernate: Session and Transaction
     
    Similar Threads
    Strange DB behavior w/hibernate
    hibernate session: to close or not to close
    Mock doesnt work
    Testing persistence or method?
    Is this Dao?