[hibernate-dev] Cascading Lock - or re-associating object graph to an open session

[Sanne Grinovero]

Hi all,
I'm needing some advice about HSEARCH-689 - MassIndexer throwing
LazyInitializationException on associated collections.

MassIndexer design reminder:
Search loads the root entity it needs to index via a Session A,
attempting to initialize as less collections as possible,
then it sends these objects to a queue, consumed by a second thread
having Session B opened; this takes the objects from the queue and
attaches them to their own session to continue processing.

 - Session A detaches objects using
   session.clear()

 - Session B attaches objects using
   session.buildLockRequest( LockOptions.NONE ).lock( take );

Now in the particular case of this issue, the object loaded by A is
having a property containing an AbstractPersistentCollection, which is
send to second thread un-initialized.
When Session B iterates over this collection, while the object is
attached, it seems the collection is not, as:
org.hibernate.collection.AbstractPersistentCollection.isConnectedToSession()
returns false because session==null;

I just verified that if this collection is annotated with
cascade={CascadeType.ALL}, then the "lock none" operation seems to be
propagated to the collection, and the indexer works.
(Same with @Cascade(value = { org.hibernate.annotations.CascadeType.LOCK }) )

So a quick workaround for this is to use the CascadeType.ALL, but what
is a batter solution for the MassIndexer ?
options:
A) DocumentBuilderIndexedEntity.java:466 should make sure the
AbstractPersistentCollection is attached, or attach it if needed.
but we would like this code area to be Hibernate independent.
B) Have core provide some method like "lock entity and all linked
collections recursively", something which performs the same as the
cascading annotations. Note that I don't need support for locking,
just LockOptions.NONE as a trick to attach the full graph.

Better ideas?

Sanne