Такое параллельное выполнение создает риск конфликтов доступа к данным. Для предотвращения упомянутых конфликтов служба задач должна взаимодействовать со службой данных. Во внутренней реализации незаметно для программиста серверной части каждая задача, планируемая службой задач, «упаковывается» в транзакцию. Транзакция гарантирует, что либо все операции задачи будут выполнены как одно целое, либо не будет выполнена ни одна из них. Кроме того, любые попытки изменения значений объектов, хранящихся в службе данных, проходят через эту службу. Если сразу несколько задач пытаются изменить один объект данных, то все эти задачи, кроме одной, отменяются и планируются заново для выполнения в будущем. Оставшаяся задача выполняется до завершения. После ее выполнения могут активизироваться другие задачи. Хотя серверный программист может указать, что данные, с которыми он обращается, могут быть изменены, это необязательно. Если объект данных просто читается, а изменяется позднее, то служба данных обнаружит факт изменения перед закреплением транзакции. Обозначение предполагаемого изменения в момент чтения – оптимизация, упрощающая раннее выявление конфликтов, но даже если вы не сообщите заранее о намерениях изменить данные, это не повлияет на правильность работы программы.
Упаковка задач в транзакции означает, что коммуникационные механизмы тоже должны быть транзакционными, а сообщения должны отправляться только при закреплении транзакции, включающей задачу-отправителя. Для решения этой задачи используются две оставшиеся основные службы стека Darkstar.
Related posts: