[hibernate-dev] HSEARCH-515 and issues with Session.clear or lock

[Emmanuel Bernard]

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.