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

[Emmanuel Bernard]

setScope(true) should not be necessary I think.
My understanding is that we do propagate the lock operations to associations assuming CascadeType.LOCK is used.
setScoped(true) means something different where the database lock is propagated to the association tables: it's a JPA 2 requirement but often a bad idea.

On 30 avr. 2010, at 13:55, Sanne Grinovero wrote:

> I think this is threadsafe, another pair of eyes won't hurt of course:
> 
> org.hibernate.search.batchindexing.IdentifierConsumerEntityProducer:135
> is first clearing the Session, making sure whatever I loaded is
> detached, and then loaded entity is pushed to a concurrentqueue -
> which has implicit locking on write & read, I can't possibly read the
> entity from this queue before it's put on the queue.
> (this queue is then read at EntityConsumerLuceneworkProducer:104
> 
> I'm looking now into EntityConsumerLuceneworkProducer:111, it's using
> the new locking strategy provided by core, I see that it needs now a
> setScope(true) and that the relations also need to map a lock
> cascading. That can be a problem, I'm likely not reattaching the whole
> graph as I did with Core 3.3 (when this was designed), are there
> alternatives you could suggest?
> 
> Sorry for my recent change [1], I didn't notice there where semantic
> changes compared to the deprecated method; the user reporting this
> promised to send me the model, hopefully I'll be able to reproduce as
> verify if that's the problem.
> 
> [1] http://fisheye.jboss.org/changelog/Hibernate/search?cs=19206
> 
> 2010/4/30 Emmanuel Bernard <emmanuel at hibernate.org>:
>> 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.
>> 
>>