Is there any good design pattern for using Hibernate in 2tier application?

I read all about it on www.hibernate.org, in this forum and also http://forum.java.sun.com/thread.jspa?threadID=700590&start=30&tstart=0.
But no solutions seems perfect.


I have found, the best solution is that:

1. you have one long living session for displaying data

2. you open separete session to edit data (you can use LockMode.UPGRADE while loading edited object)

3. you refresh data in (1) session afted edit is commited

4. user can explicitly refresh his/her data


Problems:
1. session can end in an exception when tries to lazy initialize object delete by another user (I mean you can think of some other moment, where session end with an exception), then you must close all view components and load data anew (in RCP close all views and editor uses to view) - the main problem is where to catch this exception?

2. session in (1) must evict loaded data, that are not valid after refresh


Why use long living session:

1. to make use of hibernate cache while loading object (one instance object per database object in view - which typicaly include thousands objects)

2. to make use of hibernate lazy initialization

Why use session (2) for editing:

I can change loaded object as I want without making clone (eg. large recursive clone) while user edit's it and save to database onle when he clicks SAVE.



Does any one know whether it could help to use Embedded Jboss - manual lazy initialization but high performance object cache which is very important for performance reason?

This is the matter of preferences and answer depends on application specific things. In general I would recommend to start with session-per-request because it is the simplest and most robust approach, then session-per-conversation and then try something else if necessary...

I use MVC concept to view my data to user in Tree (SWT). I have very complex object graphs - eg. metadata stored in database which describe how to render data.

So using session-per-request would led into database object duplicity. (load the same data row in two (even more) separete sessions).

Lukas

Not necessarily, nothing precludes you from storing retrieved data in the application.

But that would mean to substitute Hibernate caching in my DAOs and harcode loading all many-to-one ane one-to-many relations through it. (to gain lazy loading).

Substituting general caching with custom one might be a GOOD THING especially fo non-trivial applications. If your application is simple and generic H cache works for you well then fine, use it.

By the way you can plug your cache implementation onto H easily, just supply it with Cache and CacheFactory interfaces implementations...