[infinispan-dev] Infinispan tx, config and multithreading

[Emmanuel Bernard]

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