2015-06-09 2 views
1

Я пишу сервер с помощью Java NIO, который будет получать данные от клиента (например. Место) и будет хранить данные в базу данных с помощью Microsoft SQL Server 2012.Java NIO с базой данных SQL

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

Итак, как мне следует продолжить?

Другой поток для обработки запросов к базе данных, но как я буду отправлять запросы на этот поток и как он будет хранить их (очередь?)?

Редактировать: Если кто-то предлагает использовать асинхронную БД, скажите, у кого есть хорошая документация, и поддерживается с помощью Java и Microsoft SQL-сервера.

Желательно использовать JDBC.

Любая помощь будет оценена по достоинству.

+0

Возможно, вы захотите посмотреть [этот вопрос] (http://stackoverflow.com/questions/28128089/is-it-possible-to-access-a-database-asynchronously-through-java-nio-non- блокирование), поскольку это, по-видимому, связано. – Turing85

+0

@ Turing85 У меня есть все вопросы по stackoverflow, связанные с этим, кажется, не отвечает на мой вопрос. Все люди думают, что тот же вопрос и голос проголосовали. Вопрос, который вы упомянули, просит асинхронно получить доступ к БД и смело говорит, что он не может использовать какие-либо дополнительные потоки, тогда как я никогда не делал предположений о каких-либо! –

+0

вот почему я сказал ** кажется связанным **. А что касается нисходящего потока: я не поставил вопрос на ваш вопрос. – Turing85

ответ

0

Если вы хотите разделить получение информации на хранение в базе данных, тогда очередь - это обычный подход.

Обратите внимание, что все, что вы действительно делаете, улучшает время отклика (время задержки) и добавляет возможность ввода буфера для выравнивания всплесков нагрузки запроса. Фактическая скорость передачи данных в базу данных (пропускная способность) будет одинаковой.

Вы можете использовать одну из реализаций Java BlockingQueue в java.util.concurrent. Они являются потокобезопасными.

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

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

+0

Да! Я сделал то же самое и использовал «LinkedBlockingQueue» и использовал пул рабочих потоков для обработки запросов БД из очереди, но теперь проблема, с которой я сталкиваюсь, вызывает вызовы БД слишком медленно. * Клиент отправил местоположение, поэтому я обновил его в БД, но проблема, с которой я сейчас сталкиваюсь, заключается в том, что запрос не обрабатывается так быстро, как они поступают (очередь заполняется быстро). Любая идея, как это решить? –

+0

Используйте несколько потоков записи базы данных. Убедитесь, что они не обновляют обычные строки, поскольку они будут блокировать друг друга. Вам также может потребоваться настроить SQL Server на несколько потоков/процессов, управляющих запросами, но я не знаю о настройке SQL Server. EDIT: Я, возможно, неправильно прочитал ваш комментарий - у вас, возможно, уже есть несколько сотрудников db. В этом случае это проблема настройки db. Одним из решений является использование объемных вставок для вставки нескольких строк за раз. Это ускорит многое. – rghome

+0

Да, я думаю, что единственное, что у меня осталось, это то, как я использую запросы (пакетное обновление) и настройку БД. –

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