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