The server can generate DB_BUSY errors under load because the session repository used by the server to hold all of the client session information encounters too much database contention when multiple clients need their session information updated.
The DBXML database used for the session repository does not perform well under this condition and ends up locking out other threads from updating session information while the updates are done for the thread that has the database lock. The locking of the database is required in order to perform write operations and this can take longer than the server’s retry mechanism allows resulting in DB_BUSY errors being generated for the waiting threads.
The solution to address this issue is to remove the bottleneck of all session information being funneled through a single session repository. By having a session repository per created session the bottleneck is removed with the only side effect being an increase in the memory used by the server.
To allow for better control over the number of created session repositories a new serverconfi.ini property should be added to allow restricting this as needed. Also, in order to be more flexible a new serverconfig.ini property should be added to allow using the old repository solution or the new solution.
[ResourceServiceProperties]
# SessionRepositoriesConfig Sets whether to use a single file session
# repository or a session repository file per session.
# SingleFile or FilePerSession
# SessionRepositoriesLimit The total number of active session files allowed.
# This setting only works when FilePerSession
# is used.
SessionRepositoriesConfig = FilePerSession
SessionRepositoriesLimit = 200
Fixed. r5455