1:26 p.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev