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 <emman...@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
