Действительно ли возможно иметь, транзакции базы данных охватывают несколько запросов в направляющих?

Я думаю, что существует значение в сохранении каждой страницы, потому что, если это - продолжительный процесс и пользователь, прерван в середине, они могут хотеть сохранить свое промежуточное звено, незафиксированные результаты и погрузку, где они кончили позже.

Если бы Вы думаете, что это - хорошая идея также, то Ваш дизайн сохранил бы флаг, чтобы указать, была ли конкретная часть частью продолжительной транзакции, которая еще не была завершенной. Установите флаг, когда заключительная часть была сделана, и кнопка сохранения была нажата. Дайте значение тайм-аута, которое сказало бы, были ли промежуточные части даны "заключительное сохранение" одобрение после определенного промежутка времени, они были бы удалены.

Для ответа на конкретный вопрос я не думаю, что существует любой способ настроить транзакцию в смысле базы данных, который сделает то, что Вы хотите. Думайте об этом, и Вы будете видеть почему: нет никакой гарантии, что различные части Вашей многостраничной операции будут обработаны тем же процессом. Или довольно вероятно даже тот же сервер. Если запрос охватит соединения с базой данных, поскольку он будет в этой ситуации, незафиксированные части от одного соединения будут невидимы для других соединений.

А также идеи уже упомянули, я рассмотрел бы использование одной или нескольких таблиц "подготовки" для содержания неполных данных, уже введенных. Затем, когда пользователь закончен, единственная транзакция может применить данные к постоянным таблицам и удалить данные подготовки. Неполные данные могут быть убраны на критерии возраста фоновым процессом, после того как Вы уверены, что сессия была завершена или проведена, пока пользователь не возвращается, должен тот лучше отвечать своим требованиям.

Я склонился бы к этому подходу особенно, если бы я ожидал иметь регулярные незавершенные транзакции, потому что этот путь я не должен иметь дело с неполными данными в своих основных моделях.

Открытие транзакции базы данных, которая охватила бы несколько запросов, является плохой идеей. Рассмотрите ситуацию, где пользователь просто закрывает браузер, прежде чем Ваша транзакция будет фиксироваться. Вас оставляют с осиротевшей транзакцией, которая не является ни rolledback, ни фиксировавший.

Просто поместите флаг в базу данных что-то как REG_COMPLETE, это только установлено на последней странице процесса регистрации. Затем Вы можете filter/scrub/whatever Вы любить с той неполной записью..., возможно, посылают им электронное письмо, запрашивающее их закончить?

Я не знаю ответ на Ваш исходный вопрос, но так или иначе...

Вместо того, чтобы экономить на каждой странице, почему бы не сохранить все данные в переменной сеанса? Затем в конце у Вас может быть одна страница, которая сохраняет данные на сессии вниз к базе данных? Таким образом, Вы никогда ничего частично не сохраняли в DB.