I'm reading the book and came to page 33 where, in order to retrieve and print messages from database, authors create a Transaction and before closing session they call commit():
I wonder if this (using Transaction) is really necessary, in this exact context.
Maybe if we have a web app with several requests that may be needed, but in a standalone desktop app would that really be necessary?

There is no such thing as "no transaction" even JDBC operations without explicit transaction handling are using transactions, they are just autocommitted after each query. So explicit transaction handling is generally recommended, as it leads to less errors.

thanks for your reply.
So, correct me if i'm wrong, one can say that's a "best practice" to surround CRUD code with transaction's beginTransaction() and commit().

Yes, always use transaction demarcation (there are exceptions to this rule, but not for performance reasons, just because "you can live without" sometimes). It is much easier and better to just mark the boundaries of a unit of work properly.

thanks again for the answer.
I'm not sure if i've to start a new thread because i'm going a bit off topic here:
i'm an amateur who's building a desktop app and i can garantee that just one user can access (to modify) her persistent objects.

the idea is every user fullfills her own form period.

Following this idea, what i did is that i created the first session (during login check), kept it in a static var, call it whenever need it, and for the whole time user is working with app, she's using the very same session, since i NEVER close it, except on System.exit(0).

So far (and i tested it with several diferent users at the same time), had no problems whatsoever...

Can i eventually run into trouble?
thanks in advance

Yes, you will eventually run into trouble: the Session is also a cache, and it doesn't support any automatic eviction. That means you are slowly building up stale data and you will see this in some situations (esp. if you use load() or navigate your graph). So, we usually recommend to use a single Session only for the duration of a single Application Transaction (see chapter 4 in HiA). At least, if you don't close()/openSession() for every App Tx, make sure you clear() it from time to time.

Once again thanks a lot!

I came to my actual desing because before (when opening and closing sessions) i came across with two exceptions: something like FaliledToInitializeLazyColection and NonUniqueObjectException.

To overcome both i used respectively:
sess.update(ut); (ut is a reference to my root obj)
and
Utilitarios.currentSession().clear();
And that worked fine.

So, after this, i understood that the origin of those error msgs was when i suddenly closed session - hence i never closing any session anymore...

And i was thinking that the whole duration of user interaction was a unit of work, what looks like a wrong idea...

Again, its kind of best practice to surround it with session's currentSession() and close().

Ok, you say i can live without it in case i clear() it from time to time, so my Q is this: using clear() implies i've to reopen session elsewhere?

Uhm, from your statements I can only see that you may have to spend more time on chapters 4, 5, and 8. Your question has no short answer.

i just received the book before yesterday and still on chap 2...

i dont want to push my luck (BTW its great to be able to chat with authors) but i'd have a last Q for now:
i read page 35: automatic dirty checking, and ruhshed to my code to comment this line:
(i populated all fields in gui, user may make changes, and on submit this code executes:)
//...
Transaction t = sess.beginTransaction ();
//sess.saveOrUpdate ( ut );
t.commit ();

Well, it worked ok
Anyway, i'm prepared for beeing sent (by you) to read apropriated HiA chapters...
Thanks again

Hibernate manages the state of an object, that means in monitors it for changes. The saveOrUpdate() method is only needed for reattachment of detached objects (all of this in chapter 4). It should have a different name (and it is named merge() in Hibernate3).

great!
i've my weekend homework now :)
thanks