Exchange getChangeCount wrong in transactions

[Peter Beaman]

This is a "thought bug" - we haven't yet verified the behavior, but the design appears wrong.

A Tree has a "change count" that gets bumped every time a value is inserted or deleted. This probably doesn't work correctly with MVCC. And since the ConcurrentModificationException detector in PersistitMap uses it, PersistitMap probably misbehaves in transactions.

This is an issue primarily for OE since server doesn't use the functionality.

[Yuval Shavit (yshavit)]

What's the expected use case? It seems that Accumulators are similar and are already transactional.

[Peter Beaman (pbeaman)]

The primary use case is to allow an application to determine that a Tree had changed, so any assumptions about its state need to be re- validated. The primary (perhaps only) client of that is PersistitMap. And for PersistitMap used within transactions, the mechanism appears to be broken.

We can probably should remove getChangeCount() from the public API, but the larger issue in this bug is that PersistitMap is broken. Fortunately the fix is simple: don't use test the value of getChangeCount() within a transaction, and rely instead on the snapshot view remaining unchanged.

More generally, Tree maintains some coarse utilization statistics intended for monitoring and we will probably add more statistics in the future. Accumulator is too heavy for this use and is not required.