On 12-10-29 8:49 PM, Manik Surtani wrote:

On 19 Oct 2012, at 17:40, Mircea Markus <mircea.markus@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