[infinispan-dev] changes introduced by optimistic transactions

[Sanne Grinovero]

2011/8/2 Mircea Markus <mircea.markus at jboss.com>:
>
> On 1 Aug 2011, at 17:36, Sanne Grinovero wrote:
>
> 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.
>
> So you access the cache in two ways:
> - through batching api and
> - directly, outside the scope of a transaction
> Am I correct?
>
> Isn't it possible to have a batching implementation which doesn't rely
> on transactions, or why are you needing to add this limitation?
>
> Supporting a mixed way of accessing the cache might cause problems [1]
> (thanks to Paolo R. for this paper) and is also not consistent with the JSR
> 107's way of doing things, which doesn't go for  mixed cache.
> I'd like to get a better grasp of your use case and let's catch up from
> there. IRC?
> [1] http://www.cis.upenn.edu/acg/papers/cal06_atomic_semantics.pdf

I'm afraid we're mixing concerns, I didn't ask to allow both
transactional and non-transactional operations on the same cache, I
understand there are good reasons to not support that.

What I need is control for batching, i.e. be able to send a set of
writes on different keys at one specific point in time, combined with
the capability to avoid repeatable reads in the same cache: definitely
there are many ways to emulate a similar behaviour, I could collect
all writes in a map and then send async operations and block on them
all, or open transactions for the span of single operations when I
don't need to batch.
Consider as well that I might be pushing a thousand of packages of
10MB each, I'm not of the idea that keeping these in a distributed
transaction log is healthy for performance since I don't need rollback
capabilities, being this already handled by Lucene.

Definitely I have alternative options to explore, but it will take
more time and I don't think it would be reasonable to demand this for
5.1; also I think that batching should be supported by Infinispan
core. More importantly, we exposed batching before both
as a feature and as an API, I don't think we can take it away in a
minor release.