MRT provides fast access to mostly static reference data. This is achieved by loading the data of all the memory resident tables into memory whenever the first request is received for accessing any MRT data. The table data is maintained in memory at the application server layer which allows the server to bypass database calls altogether whenever a request to retrieve data is made. This one time front-loading of MRT data ensures that no further database calls are required for these tables since the application server can service data requests from memory.
The data maintained in MRT’s memory image is static and is loaded from a flat file which reflects a snapshot of the data in the corresponding database table. The memory image is not updated unless a new “snapshot” of data is generated from the database and the MRT is reloaded by restarting the application server. The database table that corresponds to an MRT can be updated under some conditions (described later), but those updates are reflected in the MRT only when a fresh snapshot is taken and the application server restarted, as mentioned above. Therefore, tables that undergo frequent updates are not included in MRT. Only the security tables listed in the table below are added into MRT, and no other tables may be placed into MRT.
The following security-related tables are placed in the MRT file:
Data Structure |
Database Name |
Application Resource QueryObject |
R_SC_APPL_RSRC_QRY |
Access Control (SCRACS) table |
R_SC_RSRC_ACCS |
Security QueryObject used internally, required |
q_CombOrgCode |
Secured Field Resources (SCFUSE) tables |
R_SC_RSRC_FLD |
Field Access (SCFACS) table |
R_SC_FLD_ACCS |
Field Comparison |
R_SC_FLD_CMPR |
Foreign Organization (SCFORG) table |
R_SC_FGN_ORG |
User Interface Field Security (SCUIFS) table |
R_SC_UI_FLD_SEC |
To ensure data consistency between the MRT data and the underlying database, actions such as insert, update, and delete are typically not allowed on data objects that are memory resident. At the same time, there is a need to have pages that allow the data to be set up in those tables. Hence, a mechanism is provided whereby a developer building pages can set the AMSDataSource’s MaintenanceString property to Y to indicate to the system that all updates on that page should go to the database, even though it is to a table that is loaded in memory as MRT.
Pages can be developed which allow users to update the contents of a memory resident table directly on the database. This facility is ideal for tables with infrequent updates where there will not be any application inconsistencies caused by the fact that MRT must be regenerated and the application server recycled before the changed table contents come into effect. This feature is possible only if the AllowMRTUpdate flag is set to true for the specific data object referenced (AllowMRTUpdate flag should be globally set to false in production).
To bypass running the MRT Generation process and bouncing of the application for any page listed above (excluding Application Resource QueryObject which will always needs to be read from MRT), you must add the corresponding Database Name of the page (listed above in the table) to the BypassMRTLookupList parameter in the ADV30Params.ini file. You must then bounce the application for the changes to take effect. Refer to the “Activating Security Information” topic for more information.