[infinispan-dev] Transaction table cleanup

[Vladimir Blagojevic]

On 12-10-29 8:49 PM, Manik Surtani wrote:
>
> On 19 Oct 2012, at 17:40, Mircea Markus <mircea.markus at jboss.com 
> <mailto:mircea.markus at jboss.com>> wrote:
>
>>
>> On 19 Oct 2012, at 07:41, Vladimir Blagojevic wrote:
>>
>>> On 12-10-19 4:15 AM, Manik Surtani wrote:
>>>>
>>>> You're right actually, the temporary cache created is 
>>>> transactional. it is built in the CreateCacheCommand and relies on 
>>>> the DummyTransactionManager, might be better to use batching 
>>>> perhaps? Or even not require for this cache to be transactional?
>>>>
>>>> Yes, we should keep such internal caches as simple as possible.
>>>>
>>> Mircea/Manik, it could be batch I believe. If you recall Mircea, you 
>>> and I talked about how to effectively move data across cluster 
>>> deadlock free - we even agreed we should blog post about it :-) 
>>> https://issues.jboss.org/browse/ISPN-2156
>>>
>>> Mircea/Manik could I get some advice and code review for 
>>> MapReduceManagerImpl#combine?
>> Thanks Vladimir. The only change to make 
>> is CreateCacheCommand.create, configure the cache to be batchable[1]. 
>> Then in the MapReduceManagerImpl#combine, don't use the 
>> TransactionManager.beggin/commit but the batch API.
>
> Is this in?  Have we redone M/R not to rely on transactions and 
> instead to use batching yet?  Vladimir?
>
Manik, not yet. I am done with cancellation now and I am moving onto 
this one. I've tried it over the weekend and it still deadlocks from 
time to time as described here https://issues.jboss.org/browse/ISPN-2439

This was not the case before (no changes whatsoever to m/r codebase) and 
I requested Mircea's help here. We'll convert it to batches and see to 
make sure these deadlocks do not occur.

Vladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20121030/aa78b9d9/attachment-0001.html