There are two things at stake potentially.
A session is not supposed to be thread safe, nor are entities.
Could it be that you forget to guard your threads and that a state change applied on
thread 1 is not yet seen on thread 2 (in this case the separation between the session and
the entity proxy done in LazyInitializer.unsetSession() ).
Otherwise I would bet for a clear() operation that is missing some proxies because the
check leading to the exception expects the session to be nullified in the proxy or
physically closed.
Emmanuel
On 30 avr. 2010, at 10:35, Sanne Grinovero wrote:
I'd also love to hear your opinion on HSEARCH-512: the issue is caused
by an entity loaded in a Session which is cleared, the detached entity
passed to another thread and associated to a new session using
session.buildLockRequest( LockOptions.NONE ).lock( entity );
Seems possible there's an issue with the new core 3.5.x lock() method,
or even on the session.clear() ?
If the Session.clear() could have a bug, this could explain the
performance issues reported on the other threads/issues, as the batch
operations seems to slowly slow down, looks like a leak could be
happening.