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

[Emmanuel Bernard]

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" :/
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