4.14 Build Persistence

The internal DVT dictionary and information regarding the project state, like for example the errors and warnings, are persisted on disk in the dvt database. When closing and re-opening DVT, the project is restored from the persisted information to the saved state to avoid rebuilding.

To activate this mechanism, specify the +dvt_db_location+ directive in the build configuration file, like this:

If the +dvt_db_location+ is not specified, then the Language Server will rebuild the project from scratch every time it is launched.

When the current build is other than the default one, the following location is used:

This directive is global: it has effect for all the compiled code, regardless of +dvt_init+ directives. If specified multiple times, only the first time is taken into account. This may change in the future.

DB Access Considerations

The Language Server will lock the path specified by the directive, meaning that concurrent access is not possible.

A database location is locked by a Language Server by creating a .lock file inside the specified path, containing the id of the Language Server. Only the Language Server with the id serialized in the .lock file will be able to read and write to that location.

For example:

Consider a scenario where a Language Server with id1 has acquired a lock for the specified path. This lock is represented by a file named .lock in the same path, containing 'id1'. In the event that we require running another Language Server with id2 for the same project and path, it would not be possible to restore, since it is already being held by the Language Server with id1. Consequently, the server with id2 will need to execute a complete build and will not be able to read or write to that location until the lock is released by the other server.

Note: In case the Language Server process is killed unexpectedly, the .lock file will still persist in the location and another Language Server will not be able to access the database anymore.