Нетрудно, когда пулы соединений в одной JVM выполняют несколько задач - это то, что серверы приложений делают каждый день (используя JNDI для переброски объектов по загрузчикам классов)
Интересная часть - когда у вас есть пул соединений в отдельной JVM от клиентского кода, который в этом нуждается, поскольку это не позволяет сразу запрашивать и получать соединение из пула и возвращать его впоследствии.
В основном у вас есть два варианта:
Выполнение удаленных запросов для всех ваших команд JDBC по сети. Скорее всего, это будет означать, что данные будут перемещаться по сети дважды, из базы данных в пул соединений, а затем из пула соединений в ваше приложение. Если соединения с базой данных являются очень дорогими объектами, это может быть жизнеспособным решением.
Используйте RMI, чтобы получить объект соединения из JVM пула соединений с вашей собственной машиной. Это очень дорогая операция, но, насколько мне известно, она может включать в себя классы фактических драйверов, что позволяет пулу соединений предоставлять соединения с базами данных, неизвестными вашей прикладной JVM. Для меня это имело бы смысл только в том случае, если соединения с базами данных были слишком дорогими или требовалось иметь возможность поддерживать дополнительные базы данных после развертывания без изменения первоначальных развертываний.
Обратите внимание, что основная причина наличия пулов соединений вообще заключается в том, что соединения дорого создавать, использовать в ближайшее время, а затем отбрасывать. Некоторые базы данных больше, чем другие, например MySQl (или был, когда я пытался) очень дешевый, так что, возможно, проще всего это сделать.
Итак. Прежде всего: измерьте, что ваш пул соединений вовремя покупает, а затем подумайте, стоит ли вам уделять больше времени централизации.