[infinispan-dev] Major version cleaning

[Dan Berindei]

+1 to remove the async transactional modes

+1 to remove batching

I'm ambivalent about the tree module. I think we should be able to get
it on a better footing by using the transactions API, but I'm unsure
about the amount of work needed.

The biggest problem with the tree module and batching, as I see it, is
that tree operations use FORCE_WRITE_LOCK a lot, but FORCE_WRITE_LOCK
does not compose well. If the application starts a batch and reads a
node's data/children normally, a FORCE_WRITE_LOCK read later will
*not* mean the entry in the invocation context is the latest value in
the cache, and tree operations will not behave atomically. We could
force each tree read operation to use FORCE_WRITE_LOCK, but it would
probably have a negative impact on performance. Currently we also
allow the tree module to use optimistic locking, but that means
concurrent updates either a) give inconsistent results, because the
last write wins or b) throw WriteSkewException, which the application
is likely not to handle properly.

I don't think building the tree module on top of a non-transactional
cache or the functional API is an option, because TreeCache explicitly
supports batching via startAtomic()/endAtomic().


Of course, there are also more basic problems that would need to be
solved, like the tree module apparently not working in distributed
mode:

http://stackoverflow.com/questions/29673123/infinispan-treecache-not-getting-distributed-properly

Cheers
Dan


On Mon, Feb 20, 2017 at 6:06 PM, Tristan Tarrant <ttarrant at redhat.com> wrote:
> Hi guys, we discussed about this a little bit in the past and this
> morning on IRC. Here are some proposed removals:
>
> - Remove the async transactional modes, as they are quite pointless
> - Remove batching: users should use transactions
> - Remove the tree module: it doesn't work properly, and uses batching
>
> Please cast your votes
>
> Tristan
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev