2008-11-07 2 views
2

Я работаю над проектом на основе Java, который имеет клиентскую программу, которая должна подключаться к базе данных MySQL на удаленном сервере. Это было реализовано следующим образом:Мы используем JDBC + XMLRPC + Tomcat + MySQL для выполнения потенциально больших запросов MySQL. Что лучше?

Используйте JDBC для записи SQL-запросов, которые затем выполняются как сервлет с использованием Apache Tomcat и становятся доступными через XML-RPC. Клиентский код использует XML-RPC для удаленного выполнения этих функций на основе JDBC. Это позволяет нам сохранить нашу базу данных MySQL непубличной, ограничивать использование предопределенных функций и позволяет Tomcat управлять транзакциями базы данных (о чем мне сказали лучше, чем позволить MySQL сделать это в одиночку, но я действительно не знаю, понять почему). Тем не менее, для этого подхода требуется много кодовых табличек, а Tomcat - огромный всплеск памяти на нашем сервере.

Я ищу лучший способ сделать это. Один из способов, который я рассматриваю, - сделать базу данных MySQL общедоступной, переписать код на основе JDBC в качестве хранимых процедур и ограничить общественное использование только этими процедурами. Проблема, которую я вижу в этом, заключается в том, что перевод всего кода JDBC на хранимые процедуры будет сложным и трудоемким. Я также не очень хорошо разбираюсь в разрешениях MySQL. Можно ли предоставить доступ к хранимой процедуре, которая выполняет команды select в таблице, но также запрещает произвольные операции выбора в этой же таблице?

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

Спасибо!

ответ

0

Возможно, вы можете получить оперативную память на вашем сервере менее чем за несколько дней разработки, поэтому не пишите никакого кода, если это все, что вы получаете от упражнения. Кроме того, только потому, что память используется внутри tomcat, это не означает, что сам tomcat использует ее. Память может быть использована данными или техническими недостатками вашего кода.

Если вы попробовали дополнительную оперативную память и ее съели, то это пахнет проблемой кодирования, поэтому я бы предложил использовать профилировщик или данные журнала, чтобы попытаться выяснить, что является основной причиной до изменения что-нибудь. Если причиной являются большие наборы данных, то использование базы данных напрямую только задержит неизбежное, вместо этого вам нужно будет посмотреть на такие вещи, как пейджинг, обобщение, кеширование на стороне клиента или перепроектирование клиентов, чтобы уменьшить использование дорогостоящих запросов. Использование профилировщика или просто просмотр базы кода также расскажет вам, создает ли что-то слишком много объектов (особенно строк или узлов XML) или утечки памяти.

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

Наконец, я рискну предположить, что есть много веских причин, чтобы разместить веб-уровень над вашей базой данных. Гибкость (развертывания), совместимость, контроль (над SQL) и безопасность - все это является хорошим поводом для сохранения веб-уровня.

+0

Спасибо за одобренный ответ. Недавно я использовал этот инструмент: http://www.eclipse.org/mat/, чтобы получить представление об использовании памяти. Он имеет ограничения, но, безусловно, будет отмечать любые большие структуры памяти. Удачи. – 2009-03-31 13:58:52

0

MySQL 5.0.3+ имеет привилегию выполнения, которую вы можете установить (без выбора привилегий выбора), которая должна позволить вам получить нужную функциональность.

Однако обратите внимание на это mysql bug report с JDBC (ну и много других драйверов).

При вызове [процедуру] с помощью JDBC, я получаю «java.sql.SQLException: Водитель требует декларации процедуры либо содержать„\ nbegin“или„\ п“следовать рассуждение декларации, или SELECT для mysql.proc для разбора типов столбцов. "

обходного путь является:

смотри "noAccessToProcedureBodies" в/J 5.0.3 для несколько хака, не-совместимого JDBC обходного пути.

0

Я уверен, что вы могли бы реализовать свое решение без использования большого количества котельной плиты, особенно. используя что-то наподобие Весны. Кроме того, сколько памяти есть Tomcat? Я искренне верю, что если он просто делает то, что вы описываете, он может работать менее 128 Мб (консервативная догадка).

Ваша альтернатива - «правильный по книге» способ решения проблемы. Я говорю, создаю прототип и посмотрим, как он работает.Основные проблемы, которые вы могли бы иметь являются:

  • MySQL, имеющая некоторыми важными Гочами в этом отношении
  • в MySQL Поддержка хранимых процедур слишком примитивно и заставить вас сделать много работы
  • Некоторой другой странной икота

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

+0

К сожалению, существует более одной книги. Преданные REST и Semantic Web не согласятся с вами (они увидят это как упущенную возможность), но ваш администратор базы данных задается вопросом, почему у вас был веб-уровень вообще. Парень, который поддерживает клиента, также задается вопросом, почему вы меняете то, что у вас есть! – 2008-11-08 12:32:50