Exchange getChangeCount wrong in transactions

Bug #986465 reported by Peter Beaman
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Akiban Persistit
Peter Beaman

Bug Description

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.

Revision history for this message
Yuval Shavit (yshavit) wrote :

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

Revision history for this message
Peter Beaman (pbeaman) wrote :

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.

visibility: private → public
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.