Возможен ли асинхронный вызов jdbc?

Невозможно выполнить асинхронный вызов базы данных через JDBC, но вы можете сделать асинхронные вызовы в JDBC с помощью Актеров (например, актер совершает вызовы в БД через JDBC и отправляет сообщения в третьи стороны, когда вызовы закончены), или, если вам нравится CPS, конвейерные фьючерсы (promises) (хорошая реализация Scalaz Promises)

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

Scala субъекты по умолчанию основаны на событиях (не на основе потоков) - планирование продолжения позволяет создавать миллионы участников на стандартной установке JVM.

Если вы ориентируетесь на Java, Akka Framework является реализацией модели Actor, которая имеет хороший API как для Java, так и для Scala.

Кроме того, синхронный характер JDBC имеет для меня прекрасный смысл. Стоимость сеанса базы данных намного выше, чем затраты на поток Java, который блокируется (как на переднем, так и на заднем плане) и ожидает ответа. Если ваши запросы выполняются так долго, что возможности службы-исполнителя (или обертывания фреймворков Actor/fork-join/prom

Возможно, вы могли бы использовать систему асинхронных сообщений JMS, которая очень хорошо масштабируется, ИМХО:

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

• Когда процесс SQL заканчивается, вы можете запустить обратный путь: отправить сообщение ResponseQueue с результатом процесса, а слушатель на стороне клиента принять его и выполнить код обратного вызова.

В JDBC нет прямой поддержки, но у вас есть несколько параметров, таких как MDB, Executors из Java 5.

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

Мне любопытно, почему ограниченный пул потоков не будет масштабироваться? Это пул, а не поток на запрос, чтобы порождать поток за каждый запрос. Я использую это довольно часто в режиме большой загрузки webapp, и мы пока не видели никаких проблем.

Старый вопрос, но еще немного информации. Невозможно, чтобы JDBC выдавал асинхронные запросы самой базе данных, если поставщик не предоставляет расширение JDBC и оболочку для обработки JDBC. Тем не менее, можно обернуть сам JDBC очереди обработки и реализовать логику, которая может обрабатывать очередь на одном или нескольких отдельных соединениях. Одним из преимуществ этого для некоторых типов вызовов является то, что логика, если она находится при достаточно большой нагрузке, может преобразовывать вызовы в пакеты JDBC для обработки, что значительно ускорит логику. Это наиболее полезно для вызовов, где данные вставляются, и фактический результат нужно регистрировать только в случае возникновения ошибки. Хорошим примером этого является то, что для регистрации активности пользователя выполняются вставки. Приложение не заботится, будет ли вызов завершен немедленно или через несколько секунд.

В качестве побочного примечания один продукт на рынке обеспечивает политический подход к разрешению асинхронных вызовов, подобных тем, которые я описал, асинхронно (http://www.heimdalldata.com/). Отказ от ответственности: Я являюсь соучредителем этой компании. Это позволяет использовать регулярные выражения для запросов преобразования данных, таких как вставка/обновление/удаление для любого источника данных JDBC, и будет автоматически их совместно обрабатывать для обработки. При использовании с MySQL и параметром rewriteBatchedStatements (MySQL и JDBC с rewriteBatchedStatements = true) это может значительно снизить общую нагрузку на базу данных.

Проект Ajdbc, кажется, отвечает на эту проблему http://code.google.com/p/adbcj/

В настоящее время существует 2 экспериментальных асинхронных драйвера для mysql и postgresql.

Java 5.0-исполнители могут пригодиться.

У вас может быть фиксированное количество потоков для обработки длительных операций. Вместо Runnable вы можете использовать Callable, которые возвращают результат. Результат заключен в объект Future<ReturnType>, поэтому вы можете получить его, когда он вернется.

У меня есть три варианта:

• Используйте параллельную очередь для распространения сообщений через небольшое и фиксированное количество потоков. Так что если у вас 1000 соединений, у вас будет 4 потока, а не 1000 потоков.
• Доступ к базе данных на другом node (т.е. другой процесс или машина) и клиент базы данных асинхронные сетевые вызовы, чтобы node.
• Реализовать истинную распределенную систему через асинхронные сообщения. Для этого вам понадобится очередь сообщений, такая как CoralMQ или Tibco.

Diclaimer: Я один из разработчиков CoralMQ.

Просто сумасшедшая идея: вы можете использовать шаблон Iteratee по результирующему набору JBDC, заключенному в Future/Promise

Хаммерсмит делает это для MongoBd.

Похоже, что новый асинхронный jdbc API "JDBC следующий" находится в работе.

См. презентация здесь

Вы можете загрузить API из здесь

Ниже приведен пример того, что неблокирующий jdbc api может выглядеть как Oracle, представленный на JavaOne: https://static.rainfocus.com/oracle/oow16/sess/1461693351182001EmRq/ppt/CONF1578%2020160916.pdf

Итак, похоже, что в конечном итоге действительно будут асинхронные вызовы JDBC.

Библиотека commons-dbutils поддерживает AsyncQueryRunner, который вы предоставляете ExecutorService, и возвращает Future. Стоит проверить, как это просто использовать и гарантировать, что вы не будете утечки ресурсов.

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

Изменить: Или еще лучше, просто несколько потоков. Когда поток видит что-то в очереди, он запрашивает соединение из пула и обрабатывает его.