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