Does (de-) serialization still work if a mapped class is dynamically proxied / instrumented by hibernate and its objects are deserializated in another JVM (e.g. cluster) ?

As far as I know a CGLIB generated class is not kown in another VM.

It is possible to serialize CGLIB proxies using custom "writeReplace" method, but it doe's not make any sence in this case, proxy needs session/connection to load the real object, you will need to load all objects from database before to serialize proxy.
It must be better to cluster cache (or not to use any global scope cache) and to store identifiers only out of transaction scope.

As far as I understand hibernate is cluster-safe in case of a
*session-per-transaction* usage scenario. The session will never be serialized because it simply is closed by the time my SFSB is passivated, am I right?

But how about the *session-per-application-transaction* use case? In that case my 1st level session cache is full of objects, some of them instrumented by CGLIB. Thus, after passivation of my SFSB in one container another container wont be able to deserialize my objects in another VM.

So is it true that *session-per-application-transaction* cannot be used in a cluster? If yes, is there a way to generate the proxies at build time?

you can serialize those objects fine as long as the "other" side have the proper classes in the classpath. i think something like cglib, hibernate and commons-logging should be enough.

Hi max,

I guess cglib.jar and hibernate.jar wont be sufficient in this case.

The "proper classes" is exactly what I care about : how does the other JVM know about the proxy class definition which was dynamically created by another VM? Will hibernate regenerate the proxy class on the other side ?

did you even try this before asking ?

yes hibernate does stuff to allow it to be serialized otherwise it would be freaking hard to use detached objects instead of DTO's.

/max