Hi,

I'm using Hibernate to develop the persistence services for a thick, Swing-based application - the data source (a HSQLDB database) is only ever used by a single instance of the application. After reading around about using Hibernate with thick clients, I opted for a single, long-lived hibernate session in my DAO subsystem.

Here's the problem I face: objects returned from the persistence layer to the GUI can be changed by the user. However, I only want those user changes to be persisted when the user selects the 'OK' or 'Save' button (i.e. by an explicit call to Session.update()). By default, Hibernate performs automatic dirty checking, which means that those user changes are applied straight away! What's the best way of dealing with this situation? I've heard a little about read-only transactions - will they give me what I'm looking for?

Thanks,

Peeper.

You can use FlushMode.MANUAL

But long live session does not mean unique transaction. You may define transaction boundaries based on screen validation and rollback the transaction when the user cancel the screen

Thanks for the suggestion, scesbron, but I don't see how using FlushMode.MANUAL will solve the problem. As far as I can see, FlushMode.MANUAL will only delay the act of writing to the database.

Also, I'm unsure what you mean by your statement
.
Do you really mean transactions (rather than sessions)? Would you explain further, please?

Thanks,

Peeper.

You might want to use an interceptor and mark the object dirty/clean on demand. I did that for forcing objects to be dirty.

Ie findDirty(Object entity, Serializable id, Object[] currentState, Object[] previousState, String[] propertyNames, Type[] types)

is pretty explicit

* RATE if this helps *

you can use a StatelessSession, so the session will forget about objects it has fetched, and explicit calls to update() is required.

if you are using older versions of hibernate, call evict() after fetching the entity to detach it from session, merge it again using update().

You can have one session with multiple transaction by doing a begin/commit for each action. With FlushMode.MANUAL, you don't commit your modification until you call session.flush in a transaction.
This is explained in chapter 11 of last gavin's book

From the API docs, findDirty() is called from flush(). However, I don't see how I can determine whether or not the entity has been explicitly updated (say, with a call to update()). There's an onSave() method on the Interceptor interface, but the documentation is lacking - I could grovel about in the source to get the contextual information I'm looking for.

I'd be grateful of any suggestions or clarification.

Thanks,

Peeper.

A StatelessSession would provide detached objects to the client. That would cause problems when using lazy loading (which I am) in a thick client. That's because thick clients don't have the well defined small units of work within which lazy loading occurs (c.f. web applications).

Thanks,

Peeper.