[infinispan-dev] changes introduced by optimistic transactions

[Sanne Grinovero]

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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>