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.

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. > >

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(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