Comment 2 for bug 986465

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.