# HG changeset patch # User Alain Mazy # Date 1590474112 -7200 # Node ID 76b7279e52e6e705b9c78c8f06e184e2aea27c83 # Parent 5d6d593bceb6e63087fde1e6811b3c4c42fdb388# Parent d3d0696c2258b842be3a8181392b80d421779ae3 merge diff -r d3d0696c2258 -r 76b7279e52e6 Sphinx/source/faq/scalability.rst --- a/Sphinx/source/faq/scalability.rst Tue May 26 08:21:24 2020 +0200 +++ b/Sphinx/source/faq/scalability.rst Tue May 26 08:21:52 2020 +0200 @@ -162,3 +162,40 @@ bypass arenas for large memory blocks such as DICOM files). Check out the `manpage `__ of ``mallopt()`` for more information. + + +.. _scalability-limitations: + +Known limitations +----------------- + +Exclusive access to the DB +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +As of Orthanc 1.7.0, the internal code accessing the DB is still affected +by limitations induced by the SQLite engine that was the only one originally +available at the beginning of the project: inside a single Orthanc process, +there are no concurrent access to the DB. + +One solution to avoid this limitation is to have multiple Orthanc accessing +the same DB (works only for MySQL and PostgreSQL) as presented in this `sample +`__. + +Also note that the core of Orthanc does not currently support the replay +of database transactions, which is necessary to deal with conflicts +between several instances of Orthanc that would simultaneously write +to the database. As a consequence, as of Orthanc 1.7.0, when connecting multiple +Orthanc to a single database by setting ``Lock`` to ``false``, there +should only be one instance of Orthanc acting as a writer and all the +other instances of Orthanc acting as readers only. Be careful to set +the option ``SaveJobs`` to ``false`` in the configuration file of all +the instances of Orthanc acting as readers. + +A refactoring is needed to improve the core of Orthanc in that +respect, for which we are looking for funding from the +industry. Some issues reported in our bug tracker call for this +refactoring: `issue 83 +`__, `issue 121 +`__, `issue 151 +`__. + diff -r d3d0696c2258 -r 76b7279e52e6 Sphinx/source/plugins/mysql.rst --- a/Sphinx/source/plugins/mysql.rst Tue May 26 08:21:24 2020 +0200 +++ b/Sphinx/source/plugins/mysql.rst Tue May 26 08:21:52 2020 +0200 @@ -171,3 +171,9 @@ instance of Orthanc writing to the database). For more information, please check out the :ref:`documentation for PostgreSQL `. + +Scalability +^^^^^^^^^^^ + +When configuring your MySQL plugin, ensure you've read the :ref:`scalability section +` diff -r d3d0696c2258 -r 76b7279e52e6 Sphinx/source/plugins/postgresql.rst --- a/Sphinx/source/plugins/postgresql.rst Tue May 26 08:21:24 2020 +0200 +++ b/Sphinx/source/plugins/postgresql.rst Tue May 26 08:21:52 2020 +0200 @@ -243,27 +243,6 @@ between instances of Orthanc. In particular, all these instances should share the same configuration. -Furthermore, the core of Orthanc does not currently support the replay -of database transactions, which is necessary to deal with conflicts -between several instances of Orthanc that would simultaneously write -to the database. - -As a consequence, as of Orthanc 1.7.0, when connecting multiple -Orthanc to a single database by setting ``Lock`` to ``false``, there -should only be one instance of Orthanc acting as a writer and all the -other instances of Orthanc acting as readers only. Be careful to set -the option ``SaveJobs`` to ``false`` in the configuration file of all -the instances of Orthanc acting as readers. - -A refactoring is needed to improve the core of Orthanc in that -respect, for which we are looking for funding/donation from the -industry. Some issues reported in our bug tracker call for this -refactoring: `issue 83 -`__, `issue 121 -`__, `issue 151 -`__. - - Keep-alive ^^^^^^^^^^ @@ -283,3 +262,10 @@ `enable keep-alive `__ in the configuration of your PostgreSQL server + + +Scalability +^^^^^^^^^^^ + +When configuring your PostgreSQL plugin, ensure you've read the :ref:`scalability section +`