10,730
edits
Important: Deprecating old WebView — Publish failed error
Server processes: Difference between revisions
Jump to navigation
Jump to search
→Technical aspects of process execution
| Line 64: | Line 64: | ||
If you are interested in some examples, consider starting a trial for a [[resco.FieldService]] organization. It comes with several processes preconfigured. | If you are interested in some examples, consider starting a trial for a [[resco.FieldService]] organization. It comes with several processes preconfigured. | ||
== Technical aspects of process execution == | |||
This section offers insight into how processes and plugins are executed on the server. | |||
=== Server transactions === | |||
A transaction is the propagation of one or more changes to the database. It is a sequence of operations performed as a single logical unit of work against a database and accomplished in a logical order. | |||
Resco servers use standard Microsoft SQL Server as their database engine. Every backend process, such as workflow, job, or real-time process, is defined as a single operation performed against this database. | |||
=== Processes and transactions === | |||
Workflow operations run asynchronously in a separate transaction. This transaction is propagated to the database only after the transaction containing its trigger is committed. Only 1 workflow process might be executed per organization at the same time. When several workflows are designed per 1 organization, the workflows are stacked in a queue and executed sequentially. In the case of concurrent workflows created for the same entity and triggered by the same event, the workflows are ordered by the system id and executed one by one. | |||
Real-time processes run in the same transaction as their initial trigger. That means the changes defined in a real-time process are propagated to the database in the same transaction as the create/update/delete operation that triggered it initially. Concurrent real-time processes (triggered by the same event) are propagated all in the same transaction as a sequence of operations. | |||
Jobs are scheduled, trigger-independent operations and in case the data isolation and consistency are secured, several jobs can possibly run at the same time on Resco Cloud. | |||
Even when server-side processes are designed in a manner that workflows and real-time processes are not interfering, there are cases, when concurrent data access may occur, and it is very important to ensure data integrity. | |||
=== Concurrency control === | |||
Modifications made by concurrent transactions must be isolated from the modifications made by any other concurrent transactions. Any attempts to modify data in a database require a system of control, the so-called transaction locking. | |||
The transaction locks block other transactions from modifying the data in a way that would cause problems for the prior transaction requesting the lock. Each transaction frees its locks when it is completed with either a COMMIT or ROLLBACK statement. | |||
The level of concurrency control is defined by selecting transaction isolation levels for connections. Resco SQL database uses the default, read-committed isolation level. This allows a transaction to read data previously read (not modified) by another transaction without waiting for the prior transaction to end. The server engine keeps write locks until the completion of the transaction. | |||
=== Plugins and transaction locks === | |||
A server-side plugin runs (as other server-side processes) also in a single transaction and this transaction is locking the corresponding resources according to the defined isolation level. That’s the reason why plugin assemblies in general are not designed for reading and modifying tens or hundreds of records. In that case, the plugin might be fetching and updating records for several minutes and you may temporarily undesirably lock your database. | |||
=== Multiple records update === | |||
Modification of a multitude of records should be handled rather via external services, so you’re able to fetch records separately and only after modifying them, update data to the server. In that case, you avoid the plugin assembly and transaction locks completely. | |||
Another option is to count on this limitation and execute plugin once a day via scheduled jobs, possibly during the time when temporarily database locking would not cause any major issue. | |||
Alternatively, you can use fetch operations with “NoLock” parameter to allow at least dirty reads during transactions within your plugin. | |||
=== Additional reading === | |||
* [https://docs.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide?view=sql-server-ver15#Basics Transaction Basics] | |||
[[Category:Resco Cloud]] | [[Category:Resco Cloud]] | ||