Hi,

I'm trying to use Hibernate (2.1) as the persistence layer of our GUI (Swing) applications.

I want to know, for the context of a fat client application (client/server architecture), if it is OK to have a single session for the whole application lifecycle?

Everywhere (documentation, tutorials, forums, faqs) it is mentioned that a session is a short-life object.

Scenario:

- The user uses a UI view to search for Animals by name
- While the first view is still active, the user uses a second UI view to search for Animals by region.

Now we have 2 views each containing a list of animals that matched the query. Let's say there is 1 animal that is common to both list.

Using the MVC/Observer design patterns, I should have a single domain object instance to represent this animal and 2 views attached to it.

- The user, in one of the 2 views, renames the animal name and saves it.

Still with MVC/Observer, the new animal name is written in the Model object (from the view) and modelObject.notify() is called. Notify() calls every views and tell them to update.

If I follow the documentation (use a new Session instance), the second view would contain new domain model object instances, even for the one already loaded in the first view. I would be attaching a new view to a new model object, nonsense. The goal is to be sure all views are synchronized together thru a single domain model instance...

The only way I see I could resolve this problem is by using a single hibernate session for the whole lifecycle of the editor....

I know I can use .equals() and .hashcode() to compare objects loaded from different sessions, but it doesn't adress my specific problem here...

Any idea? (hope I'm not too obscur...)

(I'll be at the public training in NYC, see you there)

Yes it is possible but may be dangerous. You may have stale data (updated elsewhere and not refreshed in your session).
What you can do is refreshing your session from time to time (ie clearing the cache).
And check the disconnect/reconnect feature, it rocks with 2-tier apporaches.

Yes, this is what I read everywhere, however I absolutely need the == JVM equality accross all my application (multiples views).



What does that actually mean? If my code modify a Domain Model Object instance, loaded and cached by the single Session, how can it be desynchronized ? I mean there's just a unique instance of it...



Calling session.evict(domain_object) when I know there are no more views attached to my domain_object would be an example of a solution?



Thanks, I'm looking at disconnect / reconnect. I thought this was disconnecting the underlying JDBC connection, but traching in the source code, it doesn't seem to be the case.

There's a Second-Level cache. When I first read on it, I thought that was exactly what I was looking for. A global cache, ensuring == JVM equality between objects manipulated accross multiple sessions. Actually, I thought I could open session1, call session1.find(), store returned objects somewhere, close session1, open session2, call session2.find(), get some objects from the db, and some from the second-level cache (with == JVM equality), close session 2, etc....

However, I receive new object instances.

Is the second level cache supposed to handle what I've just described above? Would it be the solution to my MVC/Observer approach? If I'm receiving new instances, is it because I'm not using the cache correctly? (I'm using the EHCache...)

Thanks for your help,

If you only have 1 instance of you front-end to your DB (no third R/W application and no multiple instances of your GUI), you can freely use 1 session.
session.disconnect() actually disconnect or return the connection to the pool

the 2nd level cache cannot return you the actual instance due to transaction isolation capabilities.

Cool, Thanks.

Actually, there will be multiple clients (rich clients) accessing the same db at the same time. They would have their own session instance.

Yes I could have stale date in a session cache, but I thought I could manage that situation using optimistic locking, using a version property.

Summary

1. One session per rich client instance

2. Use of session.evict( domainModelObj ) when a domainModelObj has no more reason to be cached (no more views are attached)

3. Optimistic locking (version property) to manage concurrency.

Does this sound right to you?

I would like the JDBC connection to be open for the whole application lifetype. Why should I use .disconnect and .reconnect ? How could it help me?

About the second-level cache. I read that it is a JVM level cache. However, you said it cannot return the actual instance due to transaction isolation. Now I wonder what this cache is actually doing then. If it is returning a new instance, how can we say that an object was actually second-level cached? How is it stored in this cache? Not as an object instance?

I know there are alot of questions in this post, but the most important one is: can I use 1 session per rich-client instance, safely, if managing concurrency with optimistic locking?

1. User A read an object graph
2. User B read the same graph
3. User A modifies the graph and saves it.
4. User B modifies the graph and saves it.

In step 4, I would: detect that the data changed in the persistence store(version property); warn the user about the situation and give him some options : continue (overwriting what user A did), discard (let what user A did), merge (if applicable, using property by property comparison), ...

Thanks alot for your quick answers, it helps me design our applications architecture strategy being confident that I'm on the right path.

Thanks in advance

1 session per rich client is OK
evict object if you 'feel' they may be staled.
Optimistic Locking is the way to do
Beware that a session returning an exception should be closed for consistency (repoen a new one).
disconnect is useful not to waste DB resources and connections. If you feel OK to keep every conenction open, then it's fine, don't use that.

Your assessment is really appreciated.

I'm beginning the architectural design phase now.

1. Presentation UI Layer
2. Service Layer (Command Oriented Interface with Decorated Command (Martin Fowler))
3. DAL Layer (DAOs, implementation for Hibernate)

The domain model is accessible by all of the layers.

The Presentation Layer will respect the MVC pattern and access services furnished by the Service Layer in the form of Command objects (Command Design Pattern).

The Service Layer and the domain model will contain business logic at two level: coarse and fine grained, respectively. It will manage transactions and coordination between different operations performed on the DAL Layer.

The DAL Layer will use DAOs implemented the way IBM is suggesting it: http://www-106.ibm.com/developerworks/java/library/j-dao/

A single Hibernate Session will be used througth the whole architecture (accessed throught a singleton by DAOs).

Again, thank you very much for having taken the time to answer my questions.

DAL Layer should be Data Access Layer.

If anyone has comments on that architecture, please post them.
This 3 layer architecture is the result of intensive reading on this forum and from multiple knowledge sources.

However, I would you guys to confirm it sounds right.

Thanks