[jbosscache-dev] Re: Helping out with JBCACHE-991 (Non-tx batching)

[Manik Surtani]

Hi Vincent

Thanks for offering to do this, we're more than happy with non- 
committers submitting patches for features.

The question is, do we implement this in the manner you specified or  
do we go with making the BatchModeTransactionManager production-grade  
and make this the default mechanism for batching calls, since most of  
the atomic/transactional functionality is already there.

I believe the big issue with the BMTM approach is that it is based on  
the DummyTransactionManager which may make mixing BMTM with another  
transaction manager tricky (e.g., your cache uses JBossTS for most of  
it's operations, but you want batching as well).  Perhaps one  
solution would be to re-write BMTM such that rather than using the  
DTM code, it could delegate to whichever TM you have configured.  The  
other question is, how do batches behave within an ongoing  
transaction?  Do they suspend existing txs and work outside of it?   
Or do they participate?  And if so, how can this be achieved with the  
BMTM approach given that an existing transaction may already be running?

I'm cc'ing jbosscache-dev, I expect Brian will have something to say  
about this.

Cheers,
Manik


On 28 Jul 2007, at 04:48, Vincent Marquez wrote:

>
> Regarding http://jira.jboss.com/jira/browse/JBCACHE-991 (non Tx  
> batching), the  application I work on has a similar need to this  
> and it looks like something I may be able to help out with if I  
> understand the requirements correctly.
>
> Assuming you decide to go with an API addition and add startBatch 
> (), commitBatch(), rollbackBatch(), etc. it appears fairly  
> straightforward.
>
> This feature seems doable by adding a BatchInterceptor to sit right  
> after the InvocationContextInterceptor.  Using a ThreadLocal  
> variable, we could just buffer the invocation's MethodCall if the  
> current thread and cache was inside a 'batch'.   CommitBatch could  
> simply fire off a new MethodCall "_commitBatch" that would signal  
> that BatchInterceptor to iterate through the list of batched  
> MethodCalls and re-send them down the interceptor chain.  We could  
> do this by making cacheimpl.invokeMethod accessible from  
> BatchInterceptor.  Rollback would work in the same way.  If the  
> batching is not thread specific, substitute ThreadLocal with a  
> normal variable to hold the batched MethodCalls for similar  
> functionality.
>
> If the batch operations need to be Atomic, it would be a little  
> more complicated, as we'd need some sort of two phase commit  
> mechanism similar to the way transactions work now, except without  
> the node locks I'd assume.    If this sounds correct and you're ok  
> with a non-commiter working with this part of the code, I'd be  
> happy to submit a patch.   Otherwise, I'm happy to help out by  
> continuing to test and submit bugs and bug-fixes to you and Jason.
>
> --Vincent
>
>
>

--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat