[infinispan-dev] batching API and DummyTM

Sanne Grinovero sanne.grinovero at gmail.com
Mon Sep 13 14:26:36 EDT 2010


An important feature I'm missing when using batches but not using a
transaction manager is the capability to eagerly lock keys, because
there's no unlock.
Lucene sometimes does show errors, and still I don't want to rollback
as it sort-of handles it in another way (we can discuss that in
another thread if someone is interested); also some changes might be
huge (several gigabytes affected, spread on many keys) and I can't
avoid to flush remoting operations without out-of-memory, or in other
cases I just need to make sure that the change is immediately visibile
to other threads/nodes.
Still in these common use cases I have no possibility to use lock() -
in some cases I had to spin around a potentially changing value using
CAS (clusterwide!) I'm lucky that those cases where very rare and a
retry is very unlikely to happen.

2010/9/13 Mircea Markus <mircea.markus at jboss.com>:
>
> On 13 Sep 2010, at 18:03, Manik Surtani wrote:
>
> On 13 Sep 2010, at 17:00, Mircea Markus wrote:
>
> Hi,
> Thinking some more about batching API(thanks galder!) I think its main
> benefit it brings is allowing users to use transactions without having to
> set up/download an TransactionManager.
>
> Nope.  The main benefit is atomic grouping of tasks.  This is less than full
> blown JTA (no coordination between multiple data sources).
>
> Nope :) For grouping of task, batching starts a JTA tx under the hood. The
> behaviour is the same, API is different.
>
> Very similar to what Brian was describing
> here: http://community.jboss.org/wiki/BatchModeTransactionManager
> "This is all great, but there are uses cases where it's nice to have many of
> these benefits without the involvement of a JTA Transaction"
> I think we should allow people a similar approach, having our
> own BatchModeTransactionManagerLookup and BatchModeTransactionManager.
> Again, this is something to be used when users don't need distributed
> transactions, and don't want to get their hands dirty with setting up a TM.
>
> Not sure I understand this statement - what is it that you want to do here?
>  And why?
>
> I got now. I thought that, besides specifying setInvocationBatchingEnabled
> one also needs to specify a TM for batch support. I was wrong, the confusion
> in this email. Hope I'll make up by updating the documents correctly :)
>
> Instead of BatchModeTransactionManager we can use Britronix JTA[1] as it is
> a "a simple but complete implementation of the JTA 1.1 API". Drools is using
> that and they are happy with it. Actually what about replacing our DummyTM
> with this one? Less code to maintain and our tests would be run with a
> more-close-to-spec TM.
>
> It's another dep that we really don't need.  If people want to use BTM they
> can always do so without a problem.
> The DummyTM is a couple of classes and very few LOC that hasn't changed in a
> long while.  What maintenance?  :-)
>
> Wdyt?
> Cheers
> [1] http://docs.codehaus.org/display/BTM/Home
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>



More information about the infinispan-dev mailing list