The TX Interceptor currently has a concept of wrapping calls in implicit tx's for optimistic locking.
I.e., if there is no tx and optimistic locking is true, then implicitTx is set to true - and this causes the TxInterceptor to create a tx, process the call, and when returning, commit the tx.
Not quite what you are looking for (I'd imagine batching would span several method invocations to be useful) but there may be some overlaps.
To be honest, I do think batching can be quite useful - I'm sure a lot of people use txs (unnecessarily weighty) when all they really need is a simple batching process. We could refactor out the batching currently done into a top-level construct. The Tx Interceptor would automatically set batching to true if a tx is used. Batching would also have to be enabled and disabled explicitly for this to work though:
cache.beginBatch(); cache.put().... cache.commitBatch();
If a tx is used, tx.commit() would just call cache.commitBatch(), and watch for errors to roll back on ...
Yuck ! An additonal 2 methods ? Aren't we fat enough yet ? :-)
Yes, I do think lots of folks don't need it to be transactional (ie, 2 phase protocol). So I certainly would vote for that in my PojoCache impl. :-)
What about the tx and batch interaction though? I am saying example like:
Finally, to address Bela's question. Currently we probably have like 200 apis. Add 2 would be nothing. :-) But seriously, we can delegate the API out to a BatchManager (similar to TransactionManager). That way, we will have cleaner interface.
Can't we move this into an implementation of (future, JSR 107 compliant) org.jboss.cache.Cache ?
I'm afraid that we will duplicate code for transactions, e.g. we need to maintain the modifications per 'batch', which we already do for transactions...
This is why I suggested the batching mechanism being reused by the tx management mechanism.
I.e., if we detect a call within a tx and no batching being done, we internally call batch.begin()
On tx commit time, we'd call batch.commit().
Some other things to be aware of - if a batch process has started before a tx starts, we need to commit that batch process before starting a tx - and then start a new batch for the tx.
Needs some thought either way.