Hi All,

Thank you for reading this post - we're currently evaluating hibernate as a replacement for our own custom persistence mechanism and we'd like some advice from existing users about what is generally possible. Our application is a thick client CAD package which has the following characteristics:

o Designs stored in a database
o Multiple users can run clients concurrently to work on different designs
o Object model for designs is fairly large, comprising thousands of object instances across some forty classes
o Designs reference information in the database which is shared between multiple designs

We are looking at migrating our current implementation to hibernate, but our usage pattern is somewhat different to the typical case - users may have a design open in the client for days at a time, so we cannot have a single database transaction spanning the entire session. We are currently using a bespoke persistence layer to support our requirements which has the following characteristics:

o Referential integrity is automatically maintained as with EJB; modifying a reference at one end of a bidirectional association automatically updates the other end(s)
o Supports a notification API allowing listeners to be informed of object creation, deletion and modification
o Finders and lazy population of references wrapped in their own transaction
o No behind-the-scenes flushing of dirty objects to the database (it is understood that finders will return results which don't incorporate changes in the cache)
o commit() is wrapped in its own short lived transaction and uses optimistic locking to detect concurrency violations

Can hibernate be configured to support these semantics ? We thought it might be possible to use detached object support, but it looks like the lazy loading doesn't work when objects are detached from the session. I see it is also possible to begin and end transactions multiple times within the scope of a single session, but ideally we'd like hibernate to manage this behind the scenes for finders and lazy lookups and provide a way for us to explicitly commit or rollback the changes in the cache. If this is not already directly possible, does anyone have a view on how hard it would be for us to modify hibernate to support this mode of operation ?

Best Regards,

Adam.

Hibernate supports long running transactions with optimistic semantics very well (automatic version checking).

Referential Integrity: Transparent persistence doesn't interfere with the Java semantics, so you have to create bidirectional associations by adding references on both sides manually.

Notification API: Hibernate has Lifecycle and Interceptor, much better support for a full event API in Hibernate3 comming this year.

Finders and Lazy: You can populate lazy properties/associations by a) initializing everything on load with HQL/fetch joins b) calling explicit Hibernate.initialize() or c) by attaching the object to a new Session with lock() or update() before accessing a lazy property.

No write-behind: You can set a FlushMode.

Optimistic commit: Read about long transaction support/version checking in the reference manual.

Another point about the integrity rules with POJOs: If you want to enforce bidirectional associations, just have the setter methods implement something like this: