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
