How to use DbLock.synchronize?


The doc says that member DbLock.synchronize takes a lambda_, which is a Native type. I tried several different approaches to pass a test JS function to it, but am always getting an error or such, e.g., Is there a way to have the server process API requests one at a time? and Is there a way to have the server process API requests one at a time?.

Why do I need a lock? We have the TimeMachine type[1] that – only when we ask it to renormalize and do regular evalMetrics on a source type – modifies temporarily PointPhysicalMeasurementSeries headers (with a couple of data items that we cannot pass to the custom normalizer otherwise), calls refreshNormalization on them, rolls them back, and proceeds to evalMetrics on the renormalized data. (After the evaluation, we can invalidate the renormalized data or not.)

Normally, TimeMachine.evalMetrics is called to evaluate at the current instant, i.e., it is passed an assumeNormalized:true via its spec, so it does not do the renormalization. However, it is still possible to pass an evalAt parameter that is a past instant, so that renormalization is needed in order to ignore all input data that arrived after evalAt in the custom normalize function.

Even though DbLock is used on the headers by the platform during the renormalization, there is a small gap between that point and the point when evalMetrics has obtained the renormalized data. We would like to ensure that another call to refreshNormalization in between cannot happen on the same headers, as it could result in undesired normalized data made available to evalMetrics. So one would call synchronize on TimeMachine.evalMetrics to prevent that (perhaps we can create the DbLock key based on the headers’ ids, we’re not there yet).

Another idea for using DbLock is across a cluster shared by multiple projects. Perhaps we could do some cooperative scheduling to avoid stepping on each others’ feet with heavy jobs. There could be a package shared by the projects to DbLock.synchronize over certain heavy actions, rather than doing it via Slack and such.

[1] An obsolete sketch is at TimeMachine: Evaluating metrics in the past, we use finally to rollback, and field origin on the header to pass extra information to custom normalize at evalMetrics time.