> I don't think it is *that* less efficient. Attaching those objects
> likely means refreshing them too, so the only gain you would have is
> the creation of objects, and those few instances wouldn't even be
> noticable, while the extra session size of #2 might be.
What I meant was mostly efficiency in terms of database calls, where #1 
would trigger some SQL SELECT's to retrieve the object from database, 
but in #2 & #3 an update would be triggered only if there are changes to 
the object when flushing the session. A version check can also be 
applied if the POJO is versioned.
> Did you try to make a generic model for what you want? That model
> should be able to access the current hibernate session, and on attach,
> where #1models load using the id set in that model, here they would
> just refresh the object they have.
I attach the objects I need to the ThreadLocal Hibernate Session in call 
to onAttach(). But there are problems. I attach an object using 
Session.lock() and the lock will cascade through the object graph, 
attaching associated objects depending on the cascade mode I define for 
them. However if I traverse the object graph opposite the cascade 
direction, I'll run into problems. For example I define lock cascade 
from Parent -> Children and re-attach a child, the parent wont get 
attached. So if I call child.getParent().getAddresses() the address 
collection wont be initialized and I get a lazy exception. Also I had 
issues with re-attaching serialized objects ending up having two objects 
with the same id in session. Although #2 and #3 are prettier than the 
first, I guess unless somebody finds a good solution to all these 
problems, we have to live with the ugly #1 ;-)


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Wicket-user mailing list

Reply via email to