In the future, it would be nice to add support for updates and deletes to the Criteria API - something like:

MeasurementDefinitionCriteria {
      List<Integer>  filterMeasurementDefinitionIds;
      ...
      other existing filters, which help narrow down the list of definitions to update
      ...

      // new part of the API
      Long updateCollectionInterval; // if non-null, set the collectionInterval
      Boolean updateEnabled; // if non-null, override enabled/disabled bit
 }

Here, we've enhanced the criteria API to include new parameter types,
those with the naming convention "updateXXX". If any of those are set,
then the CriteriaQueryGenerator will produce an update-statement
(instead of a select-statement), whose non-null "updateXXX" values
generate the list of fields to update on the corresponding entity.

MeasurementScheduleManagerBean {
     int updateMeasurementDefinitionsByCriteria(subject, criteria) {
        // check authorization to ensure caller has permission to update monitoring defaults
        CriteriaQueryGenerator generator = new CriteriaQueryGenerator(subject, criteria);
       // potentially add authz fragments to the generated query, to restrict the update list
        CriteriaQueryRunner<MeasurementDefinition>  queryRunner = null;
        queryRunner = new CriteriaQueryRunner(criteria, generator, entityManager);
        return queryRunner.executeUpdate();
     }
}

Notice that a new method would be added to the CriteriaQueryRunner
class, executeUpdate(). When the criteria object is not selecting
objects (requiring PageList<T> to be returned) the executeUpdate()
method can be called which will return the count of affected rows instead.

The benefit with this type of solution is that it enables users to
perform finely-tuned mass updates. Now, the same Criteria object that
was able to flexibly find MeasurementDefinition objects (today you can
search for definitions by id, name, displayName, description,
resourceTypeName, resourceTypeId, measurementCategory, measurementUnits,
numericType, dataType, displayType, enabledDisabled bit, and current
collectionInterval), and take what it finds and set new values for fields.

So with just a little work at the CriteriaQueryGenerator and
CriteriaQueryRunner layers, we have a powerful solution that can be used
to deprecate a wide variety of existing methods across many of our SLSBs.

Note: a criteria-based solution could use the same style to perform
deletes as well:

SomeManagerBean {
     int deleteSomethingByCriteria(subject, criteria) {
        // check authorization to ensure caller has permission to delete
something
        CriteriaQueryGenerator generator = new
CriteriaQueryGenerator(subject, criteria);
        CriteriaQueryRunner<SomeThing>  queryRunner = null;
        queryRunner = new CriteriaQueryRunner(criteria, generator, entityManager);
        return queryRunner.executeDelete();
     }
}

Again, the benefit is that it exposes the familiar, fine-grained search
users got from the criteria filters...but now (instead of just returning
entities across the wire) the criteria framework can update and delete
stuff too.