Project

General

Profile

Feature #9577

persist the artifacts from dynamic query parsing/conversion (including the JAST) across server restarts

Added by Greg Shah over 1 year ago. Updated 8 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

History

#1 Updated by Greg Shah over 1 year ago

  • Subject changed from persist the artifacts from dynamic query parsing (including the JAST) across server restarts to persist the artifacts from dynamic query parsing/conversion (including the JAST) across server restarts

Parsing dynamic queries is time consuming, which is why we cache them. As Ovidiu aptly notes in #9538-18, most of the time is spent in the first 2 stages where we have to wrapper the query text in a small shell of 4GL code (to make it valid and give it a buffer) and the parsing/conversion of that code to get the JAST.

We can save these artifacts across server restarts, ensuring that we reload our cache from the last run of the server. Thus we would only ever have to take the cost of parsing/conversion of each dynamic query once per server installation after the FWD version is changed and then not again for that server instance. As opposed to once per server restart. We have some customers where this will have a very big impact.

If we do this cleanly (storing our persisted cache in a single file that is easy to find and move around), it seems to me we could even take the results from one server (in a test environment) and copy the persisted cache to another server and use it there. The key restriction would be that the cache would only be sharable between servers on the same version of FWD.

#3 Updated by Ovidiu Maxiniuc over 1 year ago

Indeed, this will have a great impact for queries executed early, during server startup. We can pre-train the server and use the result as an (optionally) provided resource. There are a few issues we need to resolve/think of:
  • the cache is dynamic, it evolves during the server lifetime, only the latest queries are stored in the ExpiryCache s. Will this be updated periodically to disk or only at server shutdown? When server is restarted, will this snapshot be relevant to that moment?
  • the file format can be some kind of (zipped) XML because the main resource stored is the JAST tree. However, there are some binary or object references used in the process. We need to find solutions for those, too. For example, some nodes in JavaAst have nodes with runtime cached values, the buffer classes/DmoInfo references;
  • evidently, a snapshot will only be suitable for other instances of SAME application. How do we make sure cross-application usage is prohibited? I think we can generally use the same resource for different FWD revisions, except for some specific tagged revisions which should be written to file, which will invalidate it, if the case. We also will have to invalidate it when changes into application schema occur;
  • cache file security. The file can be altered to contain any code, including malicious intentions. Should be be signed or something so that the code is safe?

#4 Updated by Ovidiu Maxiniuc 8 months ago

In addition, from today discussion, we would want to add a 'quality' property: save only converted queries which have real chances to be reused in the next server lifetime.

For example, the data for bh:find-first("where rowid = 0x00006737") may be too particular (at least in this form) to be saved. Chances to have the record with exact PK (especially for temp-tables) are really low. This should be dropped from L1 cache dump.
However, once the literal is replaced by a substitution or other similar token, this query is very suited for L2 cache, since it will be used by all queries which load a particular record identified by its PK from same table.

Also available in: Atom PDF