[eclipselink-users] Traversing a LAZY relationship after serialization /

["Jonathan S. Fisher" <exabrial@xxxxxxxxx>]

Hello,
We've encountered the infamous
traversing-a-LAZY-relationship-after-deserialization issue.

It goes like this: After an entity is serialized and then deserialized
(like what happens after a session replication event), one encounters
an exception when attempting to traverse a LAZY relationship that was
previously not traversed:

Local Exception Stack: Exception [EclipseLink-7242] (Eclipse
Persistence Services - 2.7.14.v20231208-d05cebc9b0):
org.eclipse.persistence.exceptions.ValidationException Exception
Description: An attempt was made to traverse a relationship using
indirection that had a null Session. This often occurs when an entity
with an uninstantiated LAZY relationship is serialized and that
relationship is traversed after serialization. To avoid this issue,
instantiate the LAZY relationship prior to serialization. at
org.eclipse.persistence.exceptions.ValidationException.instantiatingValueholderWithNullSession(ValidationException.java:1026)

For more info see here:
https://eclipse.dev/eclipselink/documentation/2.5/concepts/mappingintro002.htm

I have a question, would it be possible for a Tomcat SessionManager to
recognize EclipseLink entities (it has to deserialize them all) and
somehow attach them to an EclipseLink session again?

What is fascinating to me is that LAZY relationships seem to
"magically" work between requests; The entity maintains some sort of
lifeline back eclipselink even though the transaction has been closed
out. This lifeline is lost during the serialization / deserialization
cycle.

Debugging into entities that are returned from our EntityManager, I
can see that each relationship has a field called
_persistence_xyzFieldName_vh which is a UnitOfWorkQueryValueHolder,
where xyzFieldName is the name of the LAZY relationship field. Peering
into the UnitOfWorkQueryValueHolder, I can see that it has a session
field which is a RepeatableWriteUnitOfWork.

I'm curious, if the RepeatableWriteUnitOfWork is what is being "lost"
in the serialization/deserialization cycle? If so, I'm curious if a
Tomcat SessionManager could lookup the correct eclipselink Session
somehow and set that field? (I would probably do this selectively,
using an annotation to specifically mark which objects and their
graphs should be reattached).

In addition, has anyone tried this before? Is this a bad idea for
reasons I don't comprehend?

Many thanks,
-- 
Jonathan | exabrial@xxxxxxxxx