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.


_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Reply via email to