Конфигурация базы данных

Этот раздел перенесён из документации Camunda 7 и в дальнейшем будет доработан с учётом особенностей OpenBPM Engine

Существуют два способа сконфигурировать базу данных, которая будет использоваться движком Camunda. Первая опция состоит в том, чтобы задать JDBC-свойства базы данных:

  • jdbcUrl: JDBC URL базы данных.

  • jdbcDriver: реализация драйвера для конкретного типа базы данных.

  • jdbcUsername: имя пользователя для подключения к базе данных.

  • jdbcPassword: пароль для подключения к базе данных.

Обратите внимание, что внутри себя движок использует Apache MyBatis для сохранения данных.

Источник данных, сконструированный на базе предоставленных JDBC свойств, получит настройки по умолчанию для пула соединений MyBatis. Следующие атрибуты могут быть установлены опционально для тонкой настройки этого пула соединений (взято из документации MyBatis):

  • jdbcMaxActiveConnections: максимальное количество активных соединений, которе пул соединений может содержать в любой отдельно взятый момент времени. По умолчанию равно 10.

  • jdbcMaxIdleConnections: максимальное количество бездействующих соединений, которе пул соединений может содержать в любой отдельно взятый момент времени.

  • jdbcMaxCheckoutTime: перило времении в миллисекундах, на которое соединение может быть "извлечено" из пула до его принудительного возвращения. По умолчанию равно 20000 (20 секунд).

  • jdbcMaxWaitTime: это никзоуровневая настройка, которая дает пулу шанс напечатать статус лога и повтроно попытаться получить соединение в случае, если это занимает необычно долгое время (чтобы избежать тихого падения навечно, если у пула неверная конфигурация). По умолчанию 20000 (20 секунд).

  • jdbcStatementTimeout: время в секундах, в течение которого JDBC драйвер будет ожидать ответа от базы данных. По умолчанию null, что означант, что таймаута не существует. Эта настройка не поддерживается для базы данных H2.

Пакетная обработка JDBC

Другая конфигурация — jdbcBatchProcessing — устанавливает, бдолжен ли использоваться режим пакетной обработки при отпраквке SQL запросов в базу данных. Когда отключена, запросы выполняются по одному. Значения: true (по умолчанию), false.

Известные проблемы с пакетной обработкой:

  • Пакетная обработка не работает для Oracle до 12-й версии.

  • При использовании пакетной обработки на MariaDB и DB2 игнорируется настройка jdbcStatementTimeout.

Пример конфигурации базы данных

<property name="jdbcUrl" value="jdbc:h2:mem:camunda;DB_CLOSE_DELAY=1000" />
<property name="jdbcDriver" value="org.h2.Driver" />
<property name="jdbcUsername" value="sa" />
<property name="jdbcPassword" value="" />

В качестве альтернативы может использоваться реализация javax.sql.DataSource (например, DBCP из Apache Commons):

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" >
  <property name="driverClassName" value="com.mysql.jdbc.Driver" />
  <property name="url" value="jdbc:mysql://localhost:3306/camunda?sendFractionalSeconds=false" />
  <property name="username" value="camunda" />
  <property name="password" value="camunda" />
  <property name="defaultAutoCommit" value="false" />
</bean>

<bean id="processEngineConfiguration" class="io.openbpm.bpm.engine.impl.cfg.StandaloneProcessEngineConfiguration">

    <property name="dataSource" ref="dataSource" />
    ...

Отметим, что Camunda не поставляется с библиотекой, которая позволяет задавать такой источник данных. Поэтому вам необходимо убедиться в том, что библиотеки (например, из DBCP) находятся в вашем classpath.

Следующие свойства можно задавать независимо от того, используете ли вы JDBC или подход с источником данных:

  • databaseType: задавать это свойство, как правило, нет необходимости, поскольку оно автоматически устанавливается путем анализа метаданных соединения с базой данных. Его следует устанавливать только в том случае, если автоопределение потерпело неудачу. Возможные значения: {h2, mysql, oracle, postgres, mssql, db2}. Эта настройка определяет, какие запросы и скрипты для запросов типа create/drop будут использоваться. См. раздел "Поддерживаемые базы данных", чтобы прочесть обзор поддерживаемых типов.

  • databaseSchemaUpdate: позволяет установить стратегию управления схемой базы данных при загрузке и остановке движка управления процессами.

    • true (по умолчанию): по окончании сборки движка производится проверка того, существуют ли таблицы Camunda в базе данных. Если они не существуют, они создаются. Необходимо гарантировать, что версия схемы базы данных соответствует версии библиотеки движка управления процессами, если только вы не производите пошаговое обновление. Обновления схемы базы данных должны выполняться вручную как описано в Руководстве по обновлению и миграции.

    • false: никакие проверки не выполняются, при этом предполагается, что таблицы Camunda уже существуют в базе данных. Необходимо гарантировать, что версия схемы базы данных соответствует версии библиотеки движка управления процессами, если только вы не производите пошаговое обновление. Обновления схемы базы данных должны выполняться вручную как описано в Руководстве по обновлению и миграции.

  • create-drop: Создает схему, когда движок управления процессами создается, и удаляет схему, когда движок останавливается.

Для получения информации по поддерживаемым базам данных см. Поддерживаемые окружения

Далее приведены несколько примеров JDBC URL-ов:

  • H2: jdbc:h2:tcp://localhost/camunda

  • MySQL: jdbc:mysql://localhost:3306/camunda?autoReconnect=true&sendFractionalSeconds=false

  • Oracle: jdbc:oracle:thin:@localhost:1521:xe

  • PostgreSQL: jdbc:postgresql://localhost:5432/camunda

  • DB2: jdbc:db2://localhost:50000/camunda

  • MSSQL: jdbc:sqlserver://localhost:1433/camunda

Дополнительное конфигурирование схемы базы данных

Бизнес-ключ

С момента выхода релиза Camunda 7.0.0-alpha9, уникальное ограничение для бизнес ключа удалено из таблиц для рантайма и истории, а также из скриптов создания и удаления схемы базы данных. Если вы полагаетесь на ограничение, вы можете добавить его вручную, выполнив следующие SQL запросы:

DB2

Runtime:
alter table ACT_RU_EXECUTION add UNI_BUSINESS_KEY varchar (255) not null generated always as (case when "BUSINESS_KEY_" is null then "ID_" else "BUSINESS_KEY_" end);
alter table ACT_RU_EXECUTION add UNI_PROC_DEF_ID varchar (64) not null generated always as (case when "PROC_DEF_ID_" is null then "ID_" else "PROC_DEF_ID_" end);
create unique index ACT_UNIQ_RU_BUS_KEY on ACT_RU_EXECUTION(UNI_PROC_DEF_ID, UNI_BUSINESS_KEY);

History:
alter table ACT_HI_PROCINST add UNI_BUSINESS_KEY varchar (255) not null generated always as (case when "BUSINESS_KEY_" is null then "ID_" else "BUSINESS_KEY_" end);
alter table ACT_HI_PROCINST add UNI_PROC_DEF_ID varchar (64) not null generated always as (case when "PROC_DEF_ID_" is null then "ID_" else "PROC_DEF_ID_" end);
create unique index ACT_UNIQ_HI_BUS_KEY on ACT_HI_PROCINST(UNI_PROC_DEF_ID, UNI_BUSINESS_KEY);

H2

Runtime:
alter table ACT_RU_EXECUTION add constraint ACT_UNIQ_RU_BUS_KEY unique(PROC_DEF_ID_, BUSINESS_KEY_);

History:
alter table ACT_HI_PROCINST add constraint ACT_UNIQ_HI_BUS_KEY unique(PROC_DEF_ID_, BUSINESS_KEY_);

MSSQL

Runtime:
create unique index ACT_UNIQ_RU_BUS_KEY on ACT_RU_EXECUTION (PROC_DEF_ID_, BUSINESS_KEY_) where BUSINESS_KEY_ is not null;

History:
create unique index ACT_UNIQ_HI_BUS_KEY on ACT_HI_PROCINST (PROC_DEF_ID_, BUSINESS_KEY_) where BUSINESS_KEY_ is not null;

MySQL

Runtime:
alter table ACT_RU_EXECUTION add constraint ACT_UNIQ_RU_BUS_KEY UNIQUE (PROC_DEF_ID_, BUSINESS_KEY_);

History:
alter table ACT_HI_PROCINST add constraint ACT_UNIQ_HI_BUS_KEY UNIQUE (PROC_DEF_ID_, BUSINESS_KEY_);

Oracle

Runtime:
create unique index ACT_UNIQ_RU_BUS_KEY on ACT_RU_EXECUTION
         (case when BUSINESS_KEY_ is null then null else PROC_DEF_ID_ end,
         case when BUSINESS_KEY_ is null then null else BUSINESS_KEY_ end);

History:
create unique index ACT_UNIQ_HI_BUS_KEY on ACT_HI_PROCINST
         (case when BUSINESS_KEY_ is null then null else PROC_DEF_ID_ end,
         case when BUSINESS_KEY_ is null then null else BUSINESS_KEY_ end);

PostgreSQL

Runtime:
alter table ACT_RU_EXECUTION add constraint ACT_UNIQ_RU_BUS_KEY UNIQUE (PROC_DEF_ID_, BUSINESS_KEY_);

History:
alter table ACT_HI_PROCINST add constraint ACT_UNIQ_HI_BUS_KEY UNIQUE (PROC_DEF_ID_, BUSINESS_KEY_);

Конфигурирование уровня изоляции

Большинство систем управления базами данных предоставляют четые разных уровня изоляции, которые моно устанавливать. Например, уровни, определенные в ANSI/USO SQL следующие (от низкой до высокой изоляции):

  • READ UNCOMMITTED

  • READ COMMITTED

  • REPEATABLE READS

  • SERIALIZABLE

Требуемый уровень изоляции для работы с Camunda — это READ COMMITTED, который может называться по-разному в разных СУБД. Установка уровня в REPEATABLE READS может вызывать deadlock-и,поэтому менять уровень изоляции надо с осторожностью.

При инициализации движка выполняется проверка с целью определить, отличается ли установленный уровень изоляции для БД от рекомендованного. Если он отличается, будет выброшено исключение.

Это поведение можно отключить установкой флага skipIsolationLevelCheck в true. Так можно предотвратить выбрасывание исключения, и вместо этого в лог будет записано соответствующее сообщение.

Здесь можно найти больше подробностей об этом и других свойствах.

Лицензия и атрибуция

Эта документация была создана на базе материала "Camunda 7 Docs" от Camunda, находится под лицензией Creative Commons Attribution-ShareAlike 3.0 Unported License .

Оригинал документации: https://docs.camunda.org