Hi ng,

Well, i've got a bit of a gripe about Hibernate...it's this automatic persistance of associated objects in the session. eg from doco:



What was the reasoning behind this design decision? This results in a complete loss of control of if and when objects are saved.

I'm using the open session in view pattern with a service orientated architecture and all hibernate access hidden in daos - my web tier loads business objects performs modifications and then is supposed to be forced to call the relevant service methods to save any changes. With Hibernate's session design, any changes that are made to any objects loaded within the same request will be saved when the session is flushed - this means that my whole validation architecture and exception handling mechanism can be very effectively bypassed. Added to this, all the save methods are completely useless other than for transaction management and the illusion of a robust, well designed business tier.

I already know what the reply will be - stop using open session in view and have a "single session per service call" design . The only problems with this is that I need the guarentee of instance equality and even so, this still does not solve the problem - what if a service method modifies a business object that it does not want synchronised with the database? The only option is to start doing some heavy session management by evicting objects etc.

Don't get me wrong - i love hibernate, but why does it do this and why can't you turn it off?

Comments appreciated.

Cam

Hi,

We have exactly the same questions..

SOA seems to not be compatible with ORM navigation/flush features like Hibernate does.

With hibernate DAOs do not implement CRUD (no U) the update is completely automatic (the C too with cascade persistence..).

we were constrained to do:

DAO layer clone all objects by AOP (SPRING FRAMEWORK) when transaction is in RW but we can't have the benefit of LAZY navigation in readonly ! a lot of clones are done for nothing.

we want:
- navigation / mapping in lazy for strong HQL use for finds
- update exclusively controled by business services

the only solution: no setters in business objects outside services (interfaces only are public) => quite heavy !

I don't understand that we cannot control the flush at entity level by a VETO like flag to be shure that updates are controled by a particular business layer...


Olivier ROUITS.

FlushMode.NEVER

Interceptor.onFlushDirty()
Interceptor.findDirty()