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

[Sanne Grinovero]

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.
>
>