Skip to end of metadata
Go to start of metadata

The platform working parameters can be set in one of the following ways (in the order of their priorities, lower priority at the bottom):

  • In Java code in the '' file (relevant for platform forks)
  • In which are typically part of the project and therefore function for all installations by default - parameter name should start with 'settings' (e.g., settings.enableUI)
  • In conf/ (for specific installations) - parameter name should start with 'settings'
  • In Java startup parameters - parameter name should start with 'D' prefix plus 'settings' (e.g., -Dsettings.enableUI=2)
  • In the database: Administration → System → Settings → Parameters. In this interface, you can set both global settings and settings for specific roles
  • During the execution of an action using system actions: Service.pushSetting[STRING, STRING], Service.popSetting[STRING] (overriding the value of the property for the entire current thread).

Parameter TypeDescriptionDefault

Determines user interface access, including form api

2 - Allow anonymous access

1 - Allow authenticated access only

0 - Do not allow access

1 (2 - if the server is started in development mode)

Determines access to the program interface excluding form api

2 - Allow anonymous access

1 - Allow authenticated access only

0 - Do not allow access

1 (2 - if the server is started in development mode)
freeConnectionsintMaximum number of connections in the connection pool on the application server12
statDegreeintThe base used to estimate the number of records (statistics) by all optimizers. With that, optimizers consider any number of records equal to the specified base to a certain degree (for example, if the number of records is really 1000 and the base is 5, then the optimizer considers the number of records equal to 5 to the 4th degree). Thus, the larger the base, the less accurate the statistics become, which means the compilation time, the size of the caches and generated requests are reduced, but this can significantly increase the likelihood of errors when building the correct query plan.5


intAuthentication token expiration time in minutes.60 *24 (1 day)
reserveIDStepintThe number of IDs that the application server immediately reserves for optimization when performing single object adding operations (with asynchronous input, single NEW, etc.)50



long, int

Determine the threshold and the number of iterations of memory measurement during which this threshold is exceeded after which the Java thread will be automatically interrupted. This mechanism is typically used to increase the fault tolerance of the application server.5GB, 4



Parameters of the query materialization mechanism. queryLengthTimeout defines the minimum query length for which the mechanism is enabled1000
useRequestTimeoutbooleanEnables the mechanism for repeated remote calls if these calls take too long. It is necessary for resolving situations when a call is made on the server, but the response is lost due to network problems. The latter usually happens when the application server is running in a virtualized environment. Thus, in this case, it is recommended to enable this setting and disable it in the opposite case.true



int, intDetermine the minimum lifespan threshold (in seconds) of a temporary table and the number of tables per connection, upon exceeding which these temporary tables are cleared/deleted in the routine mode. The minimum lifespan threshold for the table should be commensurate with the standard using time of the temporary table. The smaller these thresholds, the lower the resource consumption by the database server, but the higher the likelihood of "cache rotation"240, 40.



int, int

Parameters of the protection mechanism against too large queries. queryRowCountPessLimit - minimum number of records for which this protection is activated, queryRowCountOptDivider - the threshold at which the application server throws an error (is set as part of all memory available for the application server, e.g., if the parameter value is 50 and the memory capacity is 100GB, then the threshold is 100GB/50=2GB).

1000, 50
queryLengthLimitintParameters of the protection mechanism against too long queries. queryLengthLimit - the length of the request upon exceeding which the application server throws an error.2000000
remoteLogTimeintRuntime threshold (in milliseconds) at which the remote call is written to the corresponding log (server-remote)3000

explainThreshold, explainJavaStack,


int, boolean, boolean

Output parameters of query execution plan logs

  • explainThreshold - runtime threshold (in milliseconds) at which SQL request is written to the corresponding log (explain). Used only if Service.explainAnalyzeMode[User] is enabled for the user.
  • explainJavaStack - determines whether the Java stack should also be logged in addition to the LSF stack.
  • explainCompile - outputs to a special log (explaincompile) information about the compilation of the query (proposed plans, pushing conditions into subqueries, etc.).
100, false, false
startServerAnyWaybooleanStart the server, even if there are errors in the index structure or metadata synchronizationfalse



int, int

Parameters for resolving repeated update conflicts:

  • сonflictSleepThreshold - the number of unsuccessful attempts (when a conflict arose) after which the mechanism should be enabled.
  • conflictSleepTimeDegree - time base (in seconds), at the degree of which counted in the number of attempts the thread should be stopped (e.g., if the base is 2 then for 3 attempts timeout will be 8, for 4 - 16, etc.)
3, 2
timeoutNanosPerRowintThe average number of nanoseconds to process one row (is used to estimate the approximate time of the request execution). If this estimated time is exceeded, the platform tries to materialize some subqueries (or somehow change this request to a more pessimistic one) and run the query again. Reducing this parameter value may lead to more frequent materializations and additional repeated executions of the query in general, increasing it may lead to the use of incorrect plans (in the first place, nested loops on joining large tables), for example, in cases when the SQL server evaluates the subquery statistics incorrectly.20
deadLockThresholdintParameters for resolving repeated deadlocks. deadLockThreshold - the number of unsuccessful attempts (when a deadlock occurred) after which the mechanism should be enabled. 0



int, intParameters of the connection restarting mechanism. periodRestartConnections - determines how often (a period in seconds) this mechanism is launched. percentRestartConnections - determines the percentage of connections with the maximum scoring that will be restarted.60, 1
closeFormDelayintThe period provided to the client to finish processing the form after initiating its closure on the server (this mechanism is necessary for saving a round trip request when closing the form).5000
constraintRowsLimitintDetermines the number of rows that should be displayed within a constraint violation message30
defaultCompareForStringContainsbooleanUse Contains as the default filter in custom filtersfalse







int, double, int, int, int, int

Parameters for managing the complexity of changes (materialization of property changes when the complexity of incremental calculations becomes too large):

  • limitHintIncrementComplexity - complexity threshold (defined as the approximate number of executed operators). When exceeded, property changes are materialized into a temporary table. This threshold must be exceeded either by the condition that defines the object collections for which the property has changed, or directly by the value of this property (for the value it is additionally verified that the increase in complexity compared to the calculation without changes exceeds limitComplexityGrowthCoeff)
  • limitHintIncrementStat - the threshold of the estimated number of object collections for which the property changes, upon exceeding which the changes will not materialize (to avoid materialization of too large amount of data). This value is multiplied by the square of the ratio of the change complexity to the threshold (the greater the complexity, the less harm in the additional effort for maintaining a large amount of data), and also after this multiplication the resulting threshold is checked for being no less than the maximum number of records out of all used temporary tables (if less, then it is increased to this value).
  • limitHintIncrementValueComplexity - if one of the property parameters is a known constant value, its changes will not be materialized by default. At the same time, complexity can increase very quickly, so there is an additional threshold in the platform, upon exceeding which changes will be materialized even in this case (with a constant parameter). However, if a property is marked with a special COMPLEX option or depends on such a property, its changes having a constant value as one of the parameters will never be materialized.
  • limitApplyHintIncrementComplexity, limitApplyHintIncrementStat - parameters similar to the upper ones without the Apply prefix, and thus used when executing actions inside the changes applying (APPLY) operator (e.g., inside event handling)

Upon increasing all of the above parameters, the compiler and the optimizer will have more information (possibly redundant) for building more efficient plans, but will also consume more of the processor time/memory (often significantly, therefore it is not recommended to set them too large)

50, 1.5, 200, 1000, 100, 1000




long, int, int

Parameters of the excessive memory consumption preventing mechanism on the application server:

  • excessThreadAllocatedBytes - the number of bytes upon exceeding which the thread is considered as consuming too much memory
  • excessInterruptCount - the number of consecutive measurements during which the thread consumes too much memory. When exceeded, the thread will be interrupted
  • threadAllocatedMemoryPeriod - period (in seconds) that determines how often memory consumption by threads is measured
5368709120L (5GB), 4, 180 (3 minutes)





int, int,

double, double

Parameters of the mechanism for using savepoints in transactions (used to avoid restarting the entire transaction, for example, in the subquery materialization mechanism):

  • useSavePointsThreshold - the number of simultaneous savepoints on the application server. The higher, the less likely transactions will be restarted, but the more likely some DBMSs (for example, Postgres) will initiate global locks (LWLock in Postgres). This parameter is adaptive and can change depending on the actual need to use savepoints (since the savepoint mechanism is turned on only after a certain number of transaction restarts). 
  • savePointCountForExceptions - the number of transaction restarts, upon exceeding which the savepoint mechanism is enabled (-1 - fully disable). 
  • updateSavePointsMaxMultiplier, updateSavePointsMinMultiplier - the minimum and maximum coefficients that can be set by the server when adaptively determining the number of simultaneous savepoints on the application server (for example, by default these coefficients are 0.8 and 3.0, i.e. the minimum targeted number of simultaneous savepoints is 5*0.8=4, the maximum is 5*3=15)
5, -1, 0.8, 3.0
editLogicalOnSingleClickbooleanDetermines whether an event of changing a property of a logical type on the form is triggered by a single (true) or double (false) mouse clickfalse
editActionOnSingleClickbooleanDetermines whether the action call event on the form is triggered by a single (true) or double (false) mouse clickfalse

In addition to the system parameters, the platform also has launch parameters which are set a little differently and are relevant mainly for startup (initialization) processes of various components of the platform and access to these components.

  • No labels