Ограничить доступ к почтовым сообщениям от java-клиентов с помощью java-программы на сервере
Возможно, этот вопрос не очень ясен, но я не нашел более подходящих слов для заголовка, описывающего проблему, с которой я хотел бы поговорить в ближайшее время.
Я хочу ограничить доступ из настольного java-приложения к postgres.
Фон:
Предположим, у вас запущено 2 приложения, и первое приложение должно выполнить некоторые сложные вычисления на основе данных в базе данных. Чтобы закрепить неизменность данных в базе данных, я хотел бы заблокировать базу данных для операций вставки, обновления и удаления. На стороне клиента я думаю, что невозможно удовлетворительно справиться с таким поведением. Поэтому я подумал о том, чтобы использовать небольшое java-приложение на стороне сервера, которое работает как прокси. Итак, задача состоит в том, чтобы передать операции CRUD (Create Read Update Delete) до тех пор, пока он не получит команду на блокировку. После блокировки он отклоняет все операции CUD до тех пор, пока не получит команду разблокировки от клиента блокировки или не истечет время ожидания.
Вопросов:
Что вы думаете об этом подходе?
Можно ли заблокировать базу данных при таком подходе?
Вы бы предпочли Java SE или Java EE в качестве серверного Java-приложения?
Заранее спасибо.
Ответы 3
Почему бы не использовать сделки в своих операциях? База данных имеет функции для поддержания целостности данных, вместо того, чтобы прибегать к грубой операции, такой как полная блокировка базы данных.
Этот механизм блокировки, который вы описываете, кажется неприятным для пользователей. Блокировку инициируют пользователи или само программное обеспечение? Если это пользователи, вы можете ожидать некоторых проблем, когда Боб нажимает кнопку блокировки, а затем уходит на обед в течение 2 часов, забыв сначала разблокировать базу данных ...
В самом деле ... есть несколько подходящих способов справиться с этой проблемой.
- Просто заблокируйте таблицы в своем коде. В Postgresql есть команды для блокировки целых таблиц, которые вы можете запускать из своего клиентского приложения.
- Выберите уровень изоляции транзакции, при котором нет проблем с чтением данных, которые были зафиксированы после запуска txn (НАЧАЛО ПОВТОРЯЕМЫЕ ЧТЕНИЯ УРОВНЯ ИЗОЛЯЦИИ ТРАНЗАКЦИИ).
Из них наиболее эффективным является использование повторяемого чтения в качестве уровня изоляции. Postgres поддерживает это довольно эффективно и даст вам единообразное представление данных без такой тяжелой блокировки базы данных.
Год я думал о транзакциях, но в данном случае я не могу их использовать. Мне жаль, что я не упомянул это точно. Итак, предположим следующий простой случай: Расчет закрывает одну зону ответственности. После вычисления открывается новый, и ему посвящаются новые вставки. Но во время процесса вычисления вставка, обновление или удаление не допускается для данных (рассчитываемой в настоящее время) области ответственности. Более того, удаление строго запрещено, так как данные нужно архивировать.
Таким образом, использование транзакций не соответствует этому требованию. Или я что-то пропустил?
ps: (не по теме) @jsight: в настоящее время я читал, что postgres изначально отображает «повторяемое чтение» на «сериализуемое», поэтому использование «повторяемого чтения» дает вам больше ограничений, чем вы, возможно, ожидали.