Мы рады объявить еще один очень интересный пост гостя на блоге jOOQ по Фабио Tudone из параллельной вселенной .
Parallel Universe разрабатывает стек с открытым исходным кодом, который позволяет разработчикам легко кодировать чрезвычайно параллельные приложения на JVM. С помощью стека Parallel Universe вы создаете программное обеспечение, которое работает в гармонии с современным оборудованием, а не борется с ним на каждом шагу, сохраняя при этом ваш язык программирования и ваши простые, знакомые стили программирования.
Фабио Тудоне разрабатывает и поддерживает интеграционные модули Quasar в рамках проекта Comsat . Он был частью, а затем руководил разработкой облачной платформы управления корпоративным контентом в течение нескольких лет, прежде чем присоединиться к команде Parallel Universe, и он писал в основном программное обеспечение JVM на протяжении всего своего профессионального пути. В сферу его интересов входят практики Dev и DevOps, масштабируемость, параллельное и функциональное программирование, а также платформы времени исполнения. Естественно любопытный и склонный к исследованиям, он любит собирать знания и понимание от людей, мест и культур. Он также интересуется практиками осознания и любит писать всевозможные вещи.
Quasar имеет интеграцию для JDBC и jOOQ как часть проекта Comsat , так что давайте посмотрим в поле.
JDBC, JOOQ и Quasar
comsat-jdbcпредоставляет блокирующую волокно оболочку API JDBC, чтобы вы могли использовать ваше соединение внутри волокон, а не в обычных потоках Java.
Почему ты бы так поступил? Поскольку волокна — это легкие нити, и у вас может быть гораздо больше волокон, чем в вашей работающей JVM. «Еще много» означает, что мы говорим миллионы против нескольких тысяч.
Это означает, что у вас гораздо больше возможностей параллелизма в вашей системе для параллельного выполнения других задач в ожидании выполнения JDBC, будь то параллельные / параллельные вычисления (например, обмен сообщениями акторов в вашей высоконадежной системе акторов типа Quasar Erlang ) или оптоволокно — блокировка ввода / вывода (например, обслуживание веб- запросов , вызов микро-сервисов , чтение файлов через оптоволоконный NIO или доступ к другим источникам данных с поддержкой оптоволокна, таким как MongoDB ).
Если ваша БД может выдержать это, и еще несколько обычных потоков не взорвут вашу систему (пока), вы даже можете увеличить свой пул Fibre -JDBC (см. Дополнительные точки: где линия ожидания позже) и отправлять больше параллельных команд jOOQ.
Поскольку jOOQ использует соединения JDBC для доступа к базе данных, запустить jOOQ на волокнах так же просто, как ввести comsat-jooqзависимость и передать ваше соединение JDBC с поддержкой оптоволокна в контекст jOOQ:
mport java.sql.Connection;
import static org.jooq.impl.DSL.*;
// ...
Connecton conn = FiberDataSource.wrap(dataSource)
.getConnection();
DSLContext create = DSL.using(connection);
// ...Конечно, вы также можете настроить ConnectionProviderдля получения подключений от вашего FiberDataSource.
С этого момента вы можете использовать обычный jOOQ, и все будет происходить в режиме блокировки волокна , а не в потоке. Вот и все.
Нет, действительно, в этом нет ничего более: вы продолжаете использовать превосходный jOOQ, только с гораздо более эффективными волокнами, а не нитями. Quasar — хороший гражданин, и он не заставит вас использовать новый API (что особенно приятно, когда оригинальный уже хорош).
Поскольку JVM в настоящее время не поддерживает собственные зеленые потоки или продолжения , которые можно использовать для реализации легких потоков, Quasar реализует продолжения (и волокна поверх них) с помощью инструментария байт-кода . Это можно сделать во время компиляции, но часто удобнее использовать агент Quasar (особенно при работе со сторонними библиотеками), поэтому вот пример проекта Gradle на основе Dropwizard, который также включает в себя настройку агента Quasar (не забывайте о Capsuleдействительно отличный инструмент развертывания Java для любых нужд, который, разумеется, делает использование Quasar и агентов в целом очень легким). В этом примере не используются все функции jOOQ, скорее, он относится к случаю использования SQL-сборки (как для запросов, так и для CRUD), но вы можете изменить его в соответствии со своими потребностями. without-comsatВетвь содержит поточно-блокировочную версию , чтобы вы могли сравнить и увидеть (минимальное) различие с версией КомСата.
Где линия ожидания?
Возможно, вам сейчас интересно: хорошо, но JDBC — это API, блокирующий потоки, как Quasar может превратить его в блокирующий волокна ? Поскольку JDBC не имеет асинхронного режима, Quasar использует пул потоков за кулисами, в которые волокна отправляют операции JDBC и с помощью которых они размораживаются и планируются для возобновления после завершения операции JDBC ( подробнее смотрите шаблоны интеграции Quasar. Информация).
Да, вот неприятная линия ожидания : команды JDBC, ожидающие выполнения пулом потоков. Хотя вы не улучшаете параллелизм БД по сравнению с размером пула потоков JDBC, вы не наносите вреда и своим волокнам, даже если вы все еще используете простой и знакомый API блокировки. Вы все еще можете иметь миллионы волокон.
Можно ли улучшить общую ситуацию? Без стандартного асинхронного API Java RDBMS мы мало что можем сделать. Тем не менее, это может не иметь значения, если база данных является вашим узким местом. Есть несколько хороших сообщений и обсуждений на эту тему, и аргумент сводится к решению, куда вы хотите переместить очередь ожидания.
Бонус: как эта аккуратная интеграция с jOOQ работает под прикрытием?
В настоящее время Quasar требуется, чтобы разработчик (или интегратор) сказал ему, что для инструмента, хотя полностью автоматизированное оборудование находится в разработке (эта функция зависит от некоторых незначительных изменений JRE, которые не будут выпущены до Java 9). Если вы можете удобно изменить исходный код (или скомпилированные классы), то достаточно просто пометить методы @Suspendableили разрешить их throws SuspendExecution, но обычно это не так с библиотеками. Но методы с фиксированными, хорошо известными именами для инструментирования могут быть перечислены в META-INF/suspendablesи META-INF/suspendable-supers, соответственно, для конкретных методов и абстрактных / интерфейсных методов, которые могут иметь приостановленные реализации.
Если их много (или требуется генерация кода), вы можете написать a SuspendableClassifierдля интеграции с вашей интеграцией и зарегистрировать его в SPI Quasar для обеспечения дополнительной логики инструментария (см. JOOQ ). Задача А SuspendableClassifierсостоит в том, чтобы проверить информацию о подписи для каждого метода в вашем пути к классам во время выполнения на этапе инструментирования и сказать, является ли он приостанавливаемым, может ли он иметь приостановленные реализации, если точно ни тот, ни другой случай или если он не знает ( Какой-то другой классификатор мог бы сказать, возможно, «приостановленный» или «приостановленный-супер» позже).
Подводя итоги
Ну что ж… Просто наслаждайтесь отличным jOOQ на эффективных волокнах