I try some experiment and maybe need some suggestions.

The idea behind my experiment is to get rid of LazyInitializationException and detached objects in an JSF (or webapp in general) application but still using the session-per-request pattern.
The only exception is StaleObjectException on version conflict - and this is wanted.

I found a way to wrap a entity using cglib and use this wrappped instance as replacement in my code. The wrapper acts like a "transfer object" and when it comes to save it automatically merges the object with the hibernate entity. This works witout great change in my code - only a one-liner to wrap the entity.

The problem I have is that this wrapper (while still have the same signature like to orignial entity just enhanced with cglib) cant be directly used in hibernate, in particular with the criteria api.



I encapsulated all session methods so there I do not have a problem to "unwrap" my object. But I am not able to do the same with Expression et al.

So what I would like to know if there is a place where I can make a hook to unwrap my entity.
And if there is no place, is it possible to build one - aka Interceptor?

And if not, why is
org.hibernate.criterion.Expression final
and the constructor of org.hibernate.criterion.Restrictions package private.
If we could change this so that I can extend my own Expression class I could unwrap my entity there.

Thanks!

AFAICT, all that you are wanting to do can be achieved by plugging in custom tuple implementations (as in stuff from the org.hibernate.tuple package). This is the stuff used by the persisters to manage the various "entity representations". These are the things that tell hibernate how to create proxies for entities, how to marshall propertiy values to/from the entity, how to perform instantiation, etc.

This stuff is in the process of being cleaned up and exposed for configuration starting in 3.1. Usage is documented in the reference manual that comes bundled with any of the 3.1 releases (not yet pushed to the website since 3.1 is not yet final).

Here is an example from the manual:


Have a look at the org.hibernate.tuple.EntityTuplizer interface to get a feel for the kinds of things you can do here...

Oh boy, I search the forums and googled around, but never thought a possible solution could be that near.

Ok, there is much room to learn new stuff now. Will see if I manage to get things running.

Thanks for taking the time!

Hi,

Just to chime in here, I have written code to wrap all entity objects produced by Hibernate, although for a different prupose than lazy loading. I think Steve has already pointed you in the right direction with the instantiator and tupulizer classes. The other change I made was to actually change the Hibernate source code for the Hibernate#getUnderlyingClass so that it can handle my new entity proxy (this is what is causing your error).

Just to be safe, I also changed all calls to Object#getClass() in the Hibernate source code to be Hibernate#getUnderlyingClass(). I am not sure this last step is necessary.

Regards,

Ali

YES - YES - YES - YES !!!!!!

I tried the tuplizer stuff but figured out I dont want to decorate all entites.
Only if a entity is going to be detached it should be wrapped.
But then I again raised the exception above.

Did you put your patch into jira?

HIBERNATE DEVELOPERS any chance to get such a patch into the main code?????

But then, its still not enough for me :-(: I also need something like "getUnderlyingEntity"

I dont want to lazy load my objects, I just want to autmaticall attach and merge them to the current session if they are not attached or not initialized (HibernateProxy) on the first property access.

It already works if I unwrap my entity before passing it to hibernate - and its a great new feeling when writing JSF - I dont have to think to update/lock/merge them.
The only exception still thrown is the one if a version-mismatch is detected, but this is wanted.

The problem with approaches like this is that you have to have a wierd "new" operation. Seems especially dangerous in the context of JSF, where JSF is often responsible for instantiation of the object.

You can try to do stuff like this with AOP but, for various reasons, I think the long session approach is the soundest one.

Actually, the biggest (killer) problem is maintaining identity. You have no "scope".

So, this approach is actually completely broken and cannot be rescued.

I know its not safe to put such wrapped instances into a set/map as they might change its identity.
But this is not that a problem - mostly such instances are put in a member or their state is rendered into the page - or hold in an dataTable.
In any case it is hard to reattach them, but you know this ...
If you have a lot of references its not unlikely that another entity already loaded another entity - if you try to update() or lock() the detached (SAME) entity you know the exception.
The only solution is to merge() but then you will get a new instance of this object which you have to propagate then - even this is sometimes hard.


What do you mean by this? JSF create manages-beans - the backings - and a backing create new entities or load them from the database.
JSF will never instantiate a entity from its own - at least in my case.


With the wrapping stuff I can get rid of this - and on the first property access this wrapper get an identity (if it is detached) - the same of the underlaying entity.
Every property access is delegated to the real entity.
If the real entity changes its identity you might have problems too - I try to avoid this by using a surrogated key - objectId.

For now I only have Session.save() in my code - all merge/lock is in the wrapper.

Hi,

I am afraid I didn't submit a patch and it is really not suitable for a patch. I changed the method to recognize my own special proxy much as it recognizes Hibernate proxies. I am not using this to handle detached entities or anything like that, but rather for my research purposes (I also have a lot of other custom hacks :)).

Regards,

Ali