On our system, we are adding a way to load eop and tai-utc data from a database instead of a flat file. We decided to create a data provider similar to the DirectoryCrawler, but instead of looking for a file when a specific data file is called, we are calling a service that reads from the database to serve the latest data available to us. We are still using the LazyLoadedDataContext implementation.
The problem we are facing is that our user will update the EOP often. We need to make sure we have hooks to reset orekit and let it use the new data.
From our debugging it seems that if we use the Lazy implementations we get some sort of caching. So when we try to force a data read the methods that we would expect to be called to initialize the Frames are not called. We do not want to have to reset my whole service in order to use newer data.
Is there a recommended way to deal with this issue on system that are persistent (like a web service) that need to load the data or reset the data every time we run something?
I seems that to accomplish what we need we would need to implement all the interfaces implemented by the LazyLoaded classes (like LazyLoadedFrames)
I’ve addressed this problem in the past in a couple of ways.
First, it’s important to understand the implications of updating EOP data. You probably don’t want to have the EOP data change out when your application is in the middle of processing a workload. This may create inconsistencies and incorrect computation within the workload. Consider propagation with an FoV inview detection. It could potentially be unfortunate if EOP changed halfway through propagation.
So, to prevent the data context changing during a workload execution I simply grab the default context at the start of the job. Then that context object must be passed explicitly into every constructor where it’s available. This eliminates the use of any methods or classes using the default context. If you’re writing a REST application, simply create a request-scoped producer method.
@RequestScoped @Produces
public DataContext produceContext() {
return DataContext.getDefault();
}
Now that you’ve guaranteed any one single workload will use a consistent data context, simply build a new LazyLoadedDataContext, adding your custom EOP data providers.
Depending on your update periodicity, i’ve generally run a scheduled task in a background thread that re-builds the data context every 24 hours or so. Simply create the new LazyLoadedDataContext, set your data providers, then call DataContext.setDefault() to replace the default data provider.
You can simply avoid the default data context entirely, holding your “current” data context in the producer class. But I haven’t seen a clear advantage in that approach.
Hi, I have an additional question: Does this mean that it is ensured, that orekit internally does not cache any data outside of a data context (e.g. by using singleton patterns and not updating the data again after initial construction / usage of the object)?