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

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(a)hibernate.org&gt;: >> 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev