Scuse me while I don my flame-resistant overalls http://www.hudsonworkwear.com/bibs.htm...

I want everything to work exactly as it does now, except I don't want my objects persisted unless I invoke save, create, delete, etc. on an entity. Only then do I want Hibernate to save my objects, and only those objects reachable from the entity I invoked the persistence method on.

I am currently having to create state objects to act as a transient version of my business objects and it is a real pain since my business objects are already mostly usable for this purpose.

I have already explored the approach of evicting a business object from Hibernate, but the object graphs are deep and apparently Hibernate sometimes leaves a couple dependent objects in the cache that cause some interesting errors.

By default, Hibernate will not save, create or delete your objects unless you invoke those functions against them (usually in a DAO), so I don't quite understand what the issue is. Guessing...

Are you talking about wanting to stop cascaded updates or lazy reads from happening when trying to use your Hibernate-persisted objects in a disconnected state? If that's the case, then it sounds like you want your Hibernate "domain objects" to act as "data transfer objects." It's not how I'd go about it since you're throwing most of the benefits of caching and lazy reads away, but it's otherwise perfectly fine. Just set lazy=false and cascade=none in all your object mappings. You may also want to restrict automatic outer joins (or their depth).

You might also want to consider getting creative about your disconnected domain objects vs. DTOs decision. Maybe some of the others using Hibernate across stateless medium like SOAP or RMI can provide pointers on best practices. Personally I avoid DTOs like the plague, prefering to use connected domain objects whenever possible, but your needs may be different.

HTH,
Scott

Hibernate offers transparent persistence which means that any change to a persistent object is committed to the database when flush occurs. You don't have to call session.save(entity) for the changes to the objects to be persisted.



It depends on the type of application you are developing. Usually, only very simple web applications can operate without some kind of disconnected state. As soon as you add things like object validation, you need some way to alert the user without losing their changes. This is where DTO or some form of state object is invaluable.

80% of the time, transparent persistence is very convenient. I'm now focusing on the other 20%.

We are playing with state objects that extend our business objects, but it's just a tremendous waste of time to have these objects which are 99% the same as our domain objects.

It would be much more convenient to flip a switch on the Hibernate SessionFactory to not persist our entities unless we call save explicitly. Is there a class we can extend to achieve this behavior, or is the framework too integrated with "transparency" to achieve this?

Since the board is plagued with unapreciative comments at time, I'll just add that we are enjoying the framework much, and it saves us a lot of additional work. If I have to create state objects I will. I was just hoping there may be an approach that give us the best of both worlds. :)

Immediately evict() entities from the Session or clear() the Session, this makes objects transitive, hence no longer dirty checked.

We have tried the evict() approach to try and be selective about the objects that are removed from the session and have had mixed results. Sometimes, there are still some persistent objects related to the object we evict that are not removed from the session. Session.clear obviously works real well here, but is rather aggressive. :)

Can you give me a quick understanding of when the evict process stops evicting mapped objects? Have you had anyone report problems with the entire mappable object graph not being evicted when a parent object is evicted?

Also, I assume that I will probably have to use versioning in order for my transient object to cleanly reattach and persist when the time is necessary.

BTW, great writing on the Hibernate in Action book. Looking forward to the rest of the MEAP chapters soon.

evict() cascades to all associations mapped with cascade="all" or cascade="all-delete-orphans"

Hmm, I stand corrected then. I thought you always had to save the objects before closing the session. I guess old (DAO) habits die hard...

Scott