2016-04-01 7 views
0

У меня есть веб-приложение, которое получает запросы на сохранение заказов в базе данных. Я хочу писать в две разные базы данных - один экземпляр Cassandra и один экземпляр PostgreSQL. Я использую простые Java и JDBC (с apache DBUtis) с облегченной библиотекой веб-приложений на передней панели.Как управлять транзакциями по нескольким базам данных

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

Есть ли какие-либо механизмы в Java для реализации этого? Я знаю, что такое две фазы, это то, что я бы искал здесь? Есть ли альтернативы?

+1

Пожалуйста, смотрите [здесь] (http://stackoverflow.com/questions/128377/what-is-the-best-way-to-do-distributed-transactions-across-multiple-databases), который рекомендует Не делайте этого. Можете ли вы обновить свой вопрос, чтобы сообщить нам, как вы планируете использовать две базы данных? –

+1

https://en.wikipedia.org/wiki/Java_Transaction_API – Gimby

+1

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

ответ

2

Оба Cassandra & PostgreSQL поддерживает линеаризуемость и сравнение и набор (CAS), поэтому вы можете осуществлять транзакции на стороне клиента.

Если вы хотите Serializable Isolation level, тогда вы должны взглянуть на Percolator's transactions. Операции Percolator довольно известны в отрасли и используются в DynamoDB transaction library Amazon, в CockroachDB database и в самой системе Google Pecolator. A step-by-step visualization транзакций Percolator может помочь вам понять это.

Если вы ожидаете конкуренции и можете иметь дело с уровнем Read Committed изоляции, то RAMP transactions Peter Bailis может подойдет вам. Я также создал step-by-step RAMP visualization.

Третий подход заключается в использовании компенсирующих транзакций, также известных как шаблон саги. Это было описано в конце 80-х годов в газете Sagas, но стало более актуальным с повышением распределенных систем. Пожалуйста, см. Разговор Applying the Saga Pattern для вдохновения.

Смежные вопросы