[infinispan-dev] Infinispan tx, config and multithreading

[Jason T. Greene]

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 <emmanuel at 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.moren at 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 <emmanuel at 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-dev at 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