Hi,

we are developing an Swing-Application mainly for person management and deceided to use Hibernate for data persistens.

Currently I implemented the interface to the database by some repository classes (make a generic superclass bases on the dao-documentation in the hibernate wiki). The following code is the baseclass of all repositorys:

The repositorys can load, save, update and delete objects.

public class GenericHibernateRepository<T extends Persistable> implements
DomainRepository<T> {

protected Class<T> persistentClass;

protected Session session;

public GenericHibernateRepository() {
this.persistentClass = (Class<T>) ((ParameterizedType) getClass()
.getGenericSuperclass()).getActualTypeArguments()[0];
session = HibernateUtil.getSession();
}

public Class<T> getPersistentClass() {
return persistentClass;
}

public T saveOrUpdate(T entity) throws ClubConstraintViolationException {
try {
session.beginTransaction();
session.saveOrUpdate(entity);
session.getTransaction().commit();
} catch (ConstraintViolationException e) {
throw new ClubConstraintViolationException(
"error_constraintviolation", e);
} catch (RuntimeException e) {
session.getTransaction().rollback();
throw e;
}
return entity;
}

public void delete(T entity) throws ClubConstraintViolationException {
try {
session.beginTransaction();
session.delete(entity);
session.getTransaction().commit();
} catch (ConstraintViolationException e) {
throw new ClubConstraintViolationException(
"error_constraintviolation", e);
} catch (RuntimeException e) {
session.getTransaction().rollback();
throw e;
}
}

@SuppressWarnings("unchecked")
public List<T> findAll() {
try {
Criteria crit = session.createCriteria(getPersistentClass());
return crit.list();
} catch (RuntimeException e) {
session.getTransaction().rollback();
throw e;
}
}
}

The disatvantage is that it does not work like it should because of the Hibernate feature "dirty update".
Example:
1. load an object A an change a value of it
2. create a new object B and save B
-> the change of object A is in the database too. That is not expected by the user of the repository because he just wants to save object B and not to update A...

One possibility, I think, is to detache all objects that are loaded out of the repository by closing the session, but in this case lazy loading does not work. Some of the Objects in the application are very complex so I don't want to miss lazy loading.

So, do I have to remove the saveOrUpdate functionality from the repository and add methods like beginTransaction/commitTransaction?

Example implementation in the gui:
repositrory.newSession();
Object a = repository.loadObject();
repository.beginTransaction();
a.setName(Blupp); //change a
repository.commitTransaction();
repository.closeSession();

I think that is very complicated for someone who wants to use the repository and a lot of database stuff gets part of the GUI.
Are there other ways?

Thanks for ideas!

You could also use separate DTOs. This is easy in webapps that use beans to transfer data from the webapp (where users make their changes) to the business logic; you'd have to write a second set of classes to do this in a normal application.

Detaching objects will do what you need.

Perhaps a redesign would work for you. Why are you allowing users to change DB objects if you're not expecting the changes to be persisted? Shouldn't you be making the changes to temporary objects (like DTOs) instead?

Thanks for your help!
I read something about the DTOs at the SDN.
http://java.sun.com/blueprints/corej2ee ... bject.html
The main reason to use DTOs mentioned there is, that there is less network trafiic when you work on a DTOs instead of direct working on the setters of the business object on the server side.
That's no problem for our client application so first I will try the other option and detache the objects.
In the hibernate wiki "Best Practices for Thick-Client Applications (i.e., non-web apps.)" I found something about lazy fetching outside of opened session. It needs a small hack but perhaps I try it...