I have two the following scenario:

Entity A has a bidirectional @OneToMany(fetch = LAZY) @IndexedEmbedded reference to entity B.

During a transaction an existing instance of entity A is loaded from DB, changed, flushed to DB and then detached from EntityManager.

During the commit of the transaction a org.hibernate.LazyInitializationException is thrown, because Hibernate Search tries to index the instance of entity A which has been already detached.

My question is: is this a bug in Hibernate Search or functional restriction?

Is there a fundamental problem with detached entities and Hibernate Search?

If for example an entity would be changed after it has been detached, the changes would be then indexed but not peristed and therefore the state of the database and Search Index will be not in sync.

Is there a workaroud or solution for this problem?

See the test case for the problem described here:
https://github.com/wrungel/bugs/tree/master/hibernate-search-lazy-initialization-exception

Hi,
lazy initialized elements should be a resolved problem, but it will obviously need to load them during indexing as it the entry in the index structure needs to be fully rewritten.

An initialized but detached attribute should also not be a problem, however you are not expected to make changes to detached entities which are related to attached entities. In fact, I think it's a good idea to never make any change to a detached entity as that would be very surprising to other parts of a more complex system.

However the case in which you detach an entity - without changing it - and this causes you a LIE that's definitely a bug, I'll open a new bug on JIRA:

https://hibernate.atlassian.net/browse/HSEARCH-1675

thanks a lot for the tests!

I think a workaround would be to make sure you commit the transaction before you detach anything.