rhq-project/rhq — pull request #105 by jshaughn (2014-08-05 16:31:55+00:00)
Title: [1125439] Duplicate baselines metric entries

Although the root cause is still unknown the relevant code paths did not
protect against generating multiple baselines for a single schedule, even
though that should be invalid. Here are some changes that are more in line
with the 1-1 relationship that should exist between schedule and
baseline (optional for schedule, required for baseline)
- Make the db index on baseline's scheduleId unique. There should only be
one baseline for a schedule. This will prevent the problem in the BZ, possibly
at the expense of failure when trying to store a duplicate, but that would
perhaps help us pinpoint a problematic code-path.
- Use Sets (or a Map) as opposed to Lists in several places in the local API.
- Simplify and I think make more efficient the query for selecting schedules
without a current baseline. Make it return distinct ids (this is a hedge,
I don't think it would return duplicates, but this ensures that constraint).
Replace a left join with a NOT EXISTS sub select.
- Chunk the storage of baselines to prevent large Txs, don't pass entities
across Tx boundary, fetch all Schedules in one query, and (maybe) simplify the
entity manager interaction.
- Simplify some of the TransactionAttribute decls
- Mark MeasurementSchedule.baseline as an optional 1-1 relationship, just to make
it explicit on the entity.
- Fix some local SLSB jdoc