Newly created threads were not associated with any transaction, so I suppose it was a problem. Sharing transaction between threads seems to be a good solution. Thanks for help!
2009/8/13, Jason T. Greene <jason.gre...@redhat.com>: > Correct. Also there could be read races as well, so if you are going to > share a tx between threads, i would use some shared lock to gaurantee > that only one thread can use it at a time. BTW this means you have to > properly suspend/resume the TX via the TM API as well. > > Emmanuel Bernard wrote: >> Modifying a transaction means applying muations (like SQL INSERT / >> UPDATE / DELETE) to the transactional resource? >> >> On 13 août 09, at 15:07, Jason T. Greene wrote: >> >>> When using transactions, the context is bound to the transaction, and >>> you can move a transaction between threads. However, you should only >>> be modifying a transaction with one thread at a time. >>> >>> Emmanuel Bernard wrote: >>>> Could it be that you are not using the same transaction between >>>> different threads (ie you physically start different ones or >>>> different "Infinispan contexts")? >>>> Infini guys, do you support transactional operation spanning several >>>> concurrent threads? >>>> On 13 août 09, at 14:04, Łukasz Moreń wrote: >>>>> I've tried with JBoss AS transaction manager and JBossStandaloneTM. >>>>> The result is this same in all cases - error during merge. >>>>> >>>>> 2009/8/12, Emmanuel Bernard <emman...@hibernate.org>: >>>>>> Ok I understand better now. >>>>>> Do your tests in JBoss AS with it's decent transaction manager >>>>>> (infinispan should have a config for it) >>>>>> For unit testing, force the indexing process in hibernate to use a >>>>>> single thread (I ghnk it's possible ask Sanne of you don't know how). >>>>>> >>>>>> Exposing some configuration to infinispan makes sense. can you >>>>>> start a >>>>>> thread explainig what is configurable and which one you think we >>>>>> should expose to hsearch users. Ideally I would like to offer one or >>>>>> two defaut config scenarios and allow to fallback to a custom config. >>>>>> >>>>>> Emmanuel >>>>>> >>>>>> On 12 août 2009, at 11:58, Łukasz Moreń <lukasz.mo...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Sorry, but my wifi does not work well today. I will try to explain >>>>>>> it more clear. >>>>>>> >>>>>>> I'm using DummyTransactionManager available for Infinispan. >>>>>>> It associates transaction with the calling thread. >>>>>>> >>>>>>> Steps to update index: >>>>>>> >>>>>>> 1. index writer acquires lock - begin of transaction >>>>>>> >>>>>>> 2. if it is necessary, index writer delegates new threads to do >>>>>>> merge work. >>>>>>> Those merge threads do not see changes made so far from begin of >>>>>>> transaction, >>>>>>> and are looking for segments which are not yet in index. >>>>>>> Changes will be visible when AD.3 is completed. >>>>>>> For tests i tried to commit transaction when merge starts and then >>>>>>> everything worked well. But then i need to start it again. >>>>>>> >>>>>>> 3. index writer releases lock - transaction is commited, all changes >>>>>>> made in this transaction are visible for other threads. >>>>>>> >>>>>>> Maybe using some other transaction manager could help? >>>>>>> >>>>>>> What about Infinispan cache configuration? Some configuration >>>>>>> mechanism should be exposed to the user, >>>>>>> or we can hardcoded one in InfinispanDirectoryProvider is enough? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2009/8/12 Emmanuel Bernard <emman...@hibernate.org> >>>>>>> why? >>>>>>> Emmanuel Bernard >>>>>>> Pending >>>>>>> you there? >>>>>>> Emmanuel Bernard >>>>>>> Pending >>>>>>> Ok please describe in details what is going on. From what you are >>>>>>> describing the tx cannot see all segments which looks like an >>>>>>> infinispan bug to me. >>>>>>> Pending >>>>>>> >>>>>>> As a back up you can try wo transaction and see if that works >>>>>>> Emmanuel Bernard >>>>>>> Pending >>>>>>> technically the lucene index should cope with that >>>>>>> Emmanuel Bernard >>>>>>> 11:16 >>>>>>> but I like this approach less >>>>>>> >>>>>>> >>>>>>> >>>>>>> Let's try and chat by email IF I'm not online, I need to run on some >>>>>>> errands today. >>>>>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-...@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> >>> -- >>> Jason T. Greene >>> JBoss, a division of Red Hat >> > > > -- > Jason T. Greene > JBoss, a division of Red Hat > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev