2010/4/30 Emmanuel Bernard :
> 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" :/
I just thought of a new theory which is wrong-by design for sure, not
sure if that's the cause of this specific problem
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
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 o
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 lockin
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 pro
Hello,
I've shared some thoughts on HSEARCH-515 on the issue comments, I
definitely need to ask you some opinion about it.
I'll be able to implement one of the proposed solutions this weekend,
this week and next one I'm locked in a bank with bad connectivity,
so sorry communication can't be much be
