-
Type: Task
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Not Applicable
-
Storage Engines
Per session control points, they came from the original WT project. I now doubt they are useful. The reasons:
- They are designed to operate without locks since they are per-session. That means the configuration parameters should only be modified by the same session that defines the control point. That won't happen. Thus every session that has that control point will have the same configuration parameters, the ones in api_data.py.
- The example control point program shows that per-session control points can be simulated with per-connection control points. Define a different per-connection control point for each thread, i.e. each session. Each thread executes the same code containing the same define macro but passes a different control point ID so each gets a different control point. I didn't realize this would work until I did it. This makes per-session control points unnecessary. The only advantage they have is fewer control point entries in api_data.py.