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

[Sanne Grinovero]

2010/4/30 Emmanuel Bernard <emmanuel at hibernate.org>:
> BTW that would drive us to a bug in session.clear() at first sight but a test case will be needed. What surprises me is the "fails sometimes" :/

I just thought of a new theory which is wrong-by design for sure, not
sure if that's the cause of this specific problem but quite likely:
stage 1 loads a list of idenfiiers and pushes lists of identifiers to
the second stage.
Each thread on stage 2 receives a list of ids, loads it by list, but
then emits single root entities (not a list),
so some attached entities might be shared by the same root entity
(same instance, as by Session contract), and they might be handled
(attached to) different threads in stage 3.

Seems the same approach of communication between stage 1-2 should be
applied to 2-3 to make sure the entities loaded by same session are
kept in the same group, and thus handled by the same thread in
subsequent phase. Only drawback is a little less granularity in work
balancing across threads; also a bit less contention on the queue so
it shouldn't slow down much.

Sanne

> On 30 avr. 2010, at 14:10, Emmanuel Bernard wrote:
>
>> 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.
>>>>
>>>>
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>