We notice systematic Lazy Exception mass-indexation problem on embedded collection fieldbridge.
Here are the relations used :

Subscription (n) -> (1) @IndexEmbedded User (n) -> (n) @Field(...fieldBridge...) UserGroups
* user is an @IndexEmbedded field in Subscription object.
* userGroups is a Collection BridgeField (object to id) in User object.

So Subscription has a user.userGroups field which must store all the userGroups of the linked user. This field systematically throws a LazyInitializationException at reindex time.

After some investigation, I found out that only first level fields (for example user subscription) are connected to session. All the second level collection bags are not connected and throws a LazyInitializationException if we try to index them.
It appears that EntityConsumerLuceneWorkProducer relies on a side-effect for initializing lazy collection. At EntityConsumerLuceneWorkProducer.java:131 (Hibernate Search 4.0), session.buildLockRequest( LockOptions.NONE ).lock( take ); links only first level collection bags with session.

Then, in DocumentBuilderIndexedEntity:491, all fields (first or more level) are fetched without initialization, so it fails for second (or more) level lazy fields.
As objectInitializer is available in this method, it seems that it should inialize all lazy fields, without relying on lock side-effect.

Should I open a ticket on JIRA ? What is the best way to address this problem ?


Thanks

I try to add a @Cascade(CascadeType.LOCK) on "user" field in Subscription object. This enables me to end correctly reindex without any lazy exception.

So correct object initialization relies effectively on Lock event. But I am not sure that indexation should rely on this.

If anyone is interested, I create an issue on Jira : https://hibernate.onjira.com/browse/HSEARCH-1030