Чтобы открыть транзакцию нужно вызвать метод begin_transaction() у объекта db
Чтобы зафиксировать транзакцию нужно вызвать метод commit()
Т.е. Для вашего кода д.б.что-то вроде такого:
public function updateShipment($parcels) {
$this->db->begin_transaction()
$this->db->query("UPDATE " . DB_PREFIX . "shipment_parcel SET date_delivery = NOW() WHERE point_id = '" . (int)$this->session->data['point_id'] . "' AND parcel_id IN (" . implode(',', $parcels) . ")");
$this->db->query("UPDATE " . DB_PREFIX . "parcel SET date_return = '" . $this->db->escape(date('Y-m-d', strtotime('+' . $this->config->get('config_parcel_deadline') .' days'))) . "', date_modified = NOW() WHERE point_id = '" . (int)$this->session->data['point_id'] . "' AND parcel_id IN (" . implode(',', $parcels) . ")");
foreach($parcels as $parcel_id) {
$this->db->query("INSERT INTO " . DB_PREFIX . "parcel_history SET parcel_id = '" . (int)$parcel_id . "', parcel_status_id = '" . (int)$this->config->get('config_recieved_status') . "', user = '" . $this->db->escape($this->operator->getFullname()) . "', date_added = NOW(), date_modified = NOW()");
И да, использование транзакций может приводить к блокировкам, в течении того времени пока транзакция не зафиксирована или не отменена. Это значит, что изменные или добавленные в одном коннекте в транзакции записи будут не доступны в запросах из другого коннекта и запросы будут висет в ожидании того, что завершится наложившая блокировку транзакция. Но такое поведение можно скорректировать если указать уровень изоляции. Про это тоже можно почитать в указанных ссылках.
В приведённом вами коде в первой функции есть четыре запроса. Если не выполнять их в транзакции, то возможно что например первый insert отработал, а затем случился разрыв коннекта с базой и в итоге посылка зависла в непонятном состоянии. Если весь пакет из этих запросов обернуть в транзакцию, то в случае любого сбоя в любой момент выполнения пакета все, что было выполнено до момента сбоя будет возвращено в исходное состояние, т.е. в состояние до начала выполнения первого запроса пакета. Если же все ОК, то транзакция фиксируется, т.е. все изменения вступают в силу.
То что все состояния выделены в отдельные процедуры это хорошо, пусть есть дублирование, но зато код не зависим и доработав один процесс можно не опасаться регресса в других(но тесты для каждого процесса нужно написать). То что вы заложили таблицу истории в проект это тоже хорошо, аудит очень нужен, для разбора конфликтных ситуаций. Я бы заложил в проект механизм чистки или архивации для тех посылок, которые уже доставлены, например завести рядом таблицы с аналогичной структурой и постфиксом arch и переливать туда данные по посылкам, которые доставлены например месяц назад или ранее(можно сделать настраиваемым). Таким образом, оперативные таблицы не будут сильно распухать.
Могут ли одни и те же данные менять разные пользователи? Если ответ да, то синхронизацию сделать не просто. Вот на есть статья про варианты решения этой задачи. https://habrahabr.ru/company/ncloudtech/blog/264923/
Если ответ нет, тогда второй вопрос: может ли один пользователь залогиниться с разных устройств и менять свои данные, если да то тоже отсылка к предыдущей статье.
Третий вариант, ответ нет на оба вопроса. Тогда для синхронизации данных на локале и в удаленном хранилище нужно иметь уникальный ключ для данных. По этому ключу можно находить новые-удалённые записи, т.к. в этом случае ключ будет только или в удалённом или в локальном хранилище. А для поиска изменений нужно будет сравнивать по всем полям все строки таблиц у которых ключ есть и в локальном и в удалённом хранилище.
Длинна текущей последовательности. В этом hash map каждый ключ это отдельная последовательность а значение это ее длинна. Если брать ваш пример то как тот будет:
Шаг 1
Ключ = 1 значение = 1
Шаг 2
Ключ = 2 значение = 2 потому что мы продолжаем последовательность начатую на шаге 1
Шаг 3
Уже имеем две последовательности
Ключ = 2 значение 2
Ключ = 433 значение = 1
Шаг 4
Ключ = 2 значение = 2
Ключ = 433 значение = 1
Ключ = 500 значение = 1
Шаг 5
Ключ = 3 значение = 3
Ключ = 433 значение = 1
Ключ = 500 значение = 1
Шаг 6
Ключ = 3 значение = 3
Ключ = 433 значение = 1
Ключ = 500 значение = 1
Ключ = 900 значение = 1
Шаг 7
Ключ = 4 значение = 4
Ключ = 433 значение = 1
Ключ = 500 значение = 1
Ключ = 900 значение = 1
Т.е. на каждом шаге мы берём один элемент из массива и либо удлиняем имеющуюся цепочку, либо начинаем новую.
Чтобы зафиксировать транзакцию нужно вызвать метод commit()
Т.е. Для вашего кода д.б.что-то вроде такого:
public function updateShipment($parcels) {
$this->db->begin_transaction()
$this->db->query("UPDATE " . DB_PREFIX . "shipment_parcel SET date_delivery = NOW() WHERE point_id = '" . (int)$this->session->data['point_id'] . "' AND parcel_id IN (" . implode(',', $parcels) . ")");
$this->db->query("UPDATE " . DB_PREFIX . "parcel SET date_return = '" . $this->db->escape(date('Y-m-d', strtotime('+' . $this->config->get('config_parcel_deadline') .' days'))) . "', date_modified = NOW() WHERE point_id = '" . (int)$this->session->data['point_id'] . "' AND parcel_id IN (" . implode(',', $parcels) . ")");
foreach($parcels as $parcel_id) {
$this->db->query("INSERT INTO " . DB_PREFIX . "parcel_history SET parcel_id = '" . (int)$parcel_id . "', parcel_status_id = '" . (int)$this->config->get('config_recieved_status') . "', user = '" . $this->db->escape($this->operator->getFullname()) . "', date_added = NOW(), date_modified = NOW()");
$this->db->commit()
}
}
Подробнее про это можно почитать вот тут например:
php.net/manual/ru/mysqli.begin-transaction.php
www.weblibrary.biz/mysql/sintaksis-oper/uprav-tran...
https://habrahabr.ru/post/238513/
И да, использование транзакций может приводить к блокировкам, в течении того времени пока транзакция не зафиксирована или не отменена. Это значит, что изменные или добавленные в одном коннекте в транзакции записи будут не доступны в запросах из другого коннекта и запросы будут висет в ожидании того, что завершится наложившая блокировку транзакция. Но такое поведение можно скорректировать если указать уровень изоляции. Про это тоже можно почитать в указанных ссылках.