Соображения при параллельном вызове базы данных mysql
Я должен создать базу данных mysql для одновременного использования несколькими приложениями. До этого момента моим единственным опытом работы с базами данных mysql были отдельные программы (например, веб-серверы), запрашивающие базу данных. Теперь я перехожу к сценарию, в котором у меня будет несколько программ типа Java CXF-сервлетов, а также фоновое редактирование и чтение на одной и той же схеме. Я использую JDBC-драйвер Connector/J для подключения к базе данных во всех случаях.
У меня такой вопрос: что мне нужно сделать, чтобы параллельный доступ не стал проблемой. Я понимаю, что мне нужно использовать транзакции там, где это уместно, но там, где я действительно потерян, это управление. Например. Нужно ли закрывать соединение каждый раз, когда сервлет выполняет работу? Нужен ли мне уникальный пользователь для каждой программы, обращающейся к базе данных? Должен ли я что-то делать с моими объектами Connector/J? Должен ли я объявить свои таблицы по-другому? Я что-то пропустил или есть что-то, о чем я не смог придумать? У меня есть довольно хорошая идея о том, как обрабатывать транзакции и сам SQL, но я довольно растерялся, когда дело доходит до того, что мне нужно делать при настройке моей базы данных.
1 ответ
Вы должны поддерживать пул соединений. Соединения действительно дороги, чтобы создать их мысли порядка нескольких сотен миллисекунд. Поэтому для приложений большого объема имеет смысл кэшировать и использовать их повторно.
Для вашего сервлета это зависит от того, какой контейнер вы используете. Что-то вроде JBoss обеспечит пул как часть контейнера. Он может быть определен через определение источника данных и доступен через JNDI. Другие контейнеры, такие как tomcat, могут полагаться на что-то вроде C3PO.
Большинство из этих структур возвращают пользовательские реализации соединений JDBC, которые реализуют методы close() с логикой, которая возвращает соединение с пулом. Вы должны ознакомиться с деталями вашей конкретной реализации, чтобы убедиться, что вы делаете вещи так, как это поддерживается
Что касается соображений параллелизма, вам следует ознакомиться с понятиями оптимистической / пессимистической блокировки и уровней изоляции транзакций. У них есть компромиссы, в которых правильный ответ может быть определен только с учетом рабочего контекста вашего приложения.
Учитывая пользователя, у большинства приложений есть один пользователь, который представляет приложение, называемое пользователем для чтения / записи. Этот пользователь должен иметь право только на чтение и запись записей из таблиц, индексов, последовательностей и т. Д., Связанных с вашим приложением. Все экземпляры приложения будут указывать этого пользователя в строке подключения.
Если вы ознакомитесь с вышеизложенными концепциями, вы пройдете около 95% пути.
Еще кое-что. Как указано в комментариях со стороны администрации, ваш движок базы данных является огромным фактором. Вам следует ознакомиться с различиями и параметрами настройки / настройки.