Re: [infinispan-dev] changes introduced by optimistic transactions
Hi Mircea,
what you propose has a strong impact on existing use cases.
Not having batching kills the Lucene performance, and using
transactions is not an option unless the whole state of the index can
fit in memory, which is not the use case we're targeting: I need to be
able to use both on the same Cache.
Isn't it possible to have a batching implementation which doesn't rely
on transactions, or why are you needing to add this limitation?
If not, I'll have to start thinking about a different design.. not
happy about it since we got much testing from the community and I
would consider it quite stable now, but especially the performance
tests are not something I can easily reproduce on my own as it implies
big indexes, real clusters and real world use cases.
What we could do, is implement batching in the Lucene Directory itself
( a layer above Infinispan); that could work, but then again I don't
see why this could not be generalized and provide to everyone, keeping
the change less traumatic.. I'm likely not the only user of this API.
Sanne
2011/8/1 Mircea Markus <mircea.markus(a)jboss.com>:
Hi,
These is a draft of the config changes I plan to add with ISPN-1131, can you please
comment?
1.
<transaction lockingMode="optimistic"/>
The "lockingMode" attribute can have two values: optimistic(default) and
pessimistic. If pessimistic is specified then this hase the same meaning as
"useEagerLocking=true" (useEagerLocking to be deprecated).
The fluent API looks as follows:
- config.fluent().transaction().lockingModeOptimistic();
- config.fluent().transaction().lockingModePessimistic();
2.
An important restriction introduced by ISPN-1131 is the fact that a cache cannot be used
in a mixed mode: i.e. all operations run within transactions or non does.
- by specifying a "transactionManagerLookup" the user marks the cache as
transactional.
- there also is an "autoCommit" attribute: <transaction
autoCommit="true"/>
- if true (default), then user doesn't have to explicitly start and finish
single-operation transactions, but a transaction is started under the hood on user's
behalf
- if false and a call is made out of a transaction's scope then an exception
is thrown
- if the cache is not transactional then autoCommit is ignored
- a cache that supports batch operations is implicitly transactional. That's because
batching is based on transactions.
and the fluent API:
config.fluent().transaction().autoCommit(true);
Cheers,
Mircea
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev