Re: [hibernate-dev] HSEARCH-515 and issues with Session.clear or lock
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(a)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.