Ah I thought it was using multiple threads because of your mass indexing. I did not know some threads were span specifically for the Infinispan directory.
On 13 août 09, at 17:34, Sanne Grinovero wrote: > Hi Łukasz, > what is your usage of these threads? did you consider using one > transaction per thread? > > Sanne > > 2009/8/13 Łukasz Moreń <lukasz.mo...@gmail.com>: >> 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 >>> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-...@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > 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
