FWD » Core Development » Database

It seems that we may shift into dynamic mode in AdaptiveQuery more frequently than one might expect. I would have thought that editing the index we are navigating from within a FOR loop would be quite rare. But it seems from some recent analysis that this occurs with some frequency.

We need some visibility into this to know how frequently it really occurs. If it happens often, knowing why the shift occurs would also be quite important.

Based on this information we might take some specific action:

• check if we are too aggressive in shifting and refine our logic to avoid unnecessary shifts
• modify the 4GL code to avoid this (if it does happen rarely enough or in a small number of very critical places)
• add a configuration option for an incompatible AdaptiveQuery mode which never shifts into dynamic mode even when it should
• OR some other better idea

• the name of the AdaptiveQuery: procedure it was defined / method / id
• if a query is scrolling / non-scrolling (the total number of each type / per query)
• the number of invalidations (total / total avg / per query)
• the number of revalidations (total / total avg / per query)
• the number of "steps" (next operations) before the first invalidation (or the end if no invalidation) (total avg / per query)
• the number of "steps" (next operations) in total in preselect mode (total avg / per query / % of total steps in query)
• the number of "steps" (next operations) after the first invalidation and before the first revalidation (or the end if no revalidation) (or 0 if no invalidation) (total avg / per query)
• the number of "steps" (next operations) in total in dynamic mode (total avg / per query / % of total steps in query)
• the number of "steps" (next operations) in total in any mode (total avg / per query)
• the number of milliseconds (next operations) in total in preselect mode (total avg / per query / % of total time in query)
• the number of milliseconds (next operations) in total in dynamic mode (total avg / per query / % of total time in query)
• the number of milliseconds (next operations) in total in any mode (total avg / per query)
• other kind of data ("first", "last", "prev", "reposition" etc.)

I used: (total = total over all queries, total avg = total over all queries / number of queries, per query = information per each AdaptiveQuery tracked).

Committed 6708a/rev.14327. Added an initial version for tracing AdaptiveQuery and important data related to it.

Alexandru Lungu wrote:

• the name of the AdaptiveQuery: procedure it was defined / method / id
• if a query is scrolling / non-scrolling (the total number of each type / per query)
  ...
• the number of milliseconds (next operations) in total in any mode (total avg / per query)
• other kind of data ("first", "last", "prev", "reposition" etc.)

Currently almost all of the points mentioned by Alexandru were solved, except gathering data for other methods ("first", "last", "prev", etc.) which I am still working on. I think that the amount of data gathered will allow Radu to start working on this task while I continue to coordinate my work with #5307 and #6709.

I have no objection.

Eric: Where should the changes go? I'd prefer 3821c.

3821c is fine. Thanks.

I rebased 6708a with 3821c. Danut, you can now move the changes from 6708a to 3821c.

Committed 3821c/rev.14384. I applied all the suggestions mentioned by Alexandru in #6708-7 and moved all the changes from branch 6708a to 3821c.

• added stateChanged, doubleCheckInvalidation methods in the list of traced methods.
• displayed the number of calls to stateChanged and number of true/false values returned by doubleCheckInvalidation.
• ignored coreFetch since I had trouble adding it to the method list and noticed that it wasn't called at all when tracing in a large application.

• Add a column for Total number of calls for each method inside each AdaptiveQuery (it should be the first column). Basically it is the sum of Calls in Preselect Mode and Calls in Dynamic Mode
• Invert the stateChanged/invalidate (ratio): to invalidate/stateChanged (ratio).
• Mention how many AdaptiveQueries were tracked in the overview data. Also mention how many were invalidated at least once. When OUTPUT_ALL_QUERIES is not set, I can't tell how many queries were in total. Consider Total number of queries and Total number of invalidated queries

Committed 3821c/rev.14395. Made the changes mentioned in #6708-12 and fixed a problem where preselect and dynamic calls were wrongly assigned.

• added a Total number of calls column for each AdaptiveQuery.
• inverted stateChanged/invalidate (ratio)
• Added Total number of queries and Total number of invalidated queries in the overview data.
• preselect/dynamic operations are now counted after joinPoint.proceed()
• changed wrong value used in displaying operation time of preselect calls

Committed 3821c/rev.14409. Made a change in order to display the parent methods in the 4GL code by the number of calls.

The method and number of calls are displayed after the Overview data in a descending order. This change will help with finding out which line from the converted code resulted in the most AdaptiveQuery instances being created. I also added a flag named PARENT_CALL_AMOUNT_LIMIT which is used to display queries that have equal or more calls than it's value (current value is 3) and keep in mind that this flag is influenced by OUTPUT_ALL_QUERIES which displays only the invalidated queries (or all of them).