Datasource java что это
Настройка Datasource в JBoss
При разработке WEB-приложения альтернативой применения JDBC-подключения к серверу БД можно выбрать класс DataSource, использующего JNDI (Java Naming and Directory Interface). В статье рассматривается вопрос настройки DataSource в сервере приложений JBoss для подключения к серверу БД Oracle. Более подробную информацию о службе имен и каталогов JNDI можно найти на нашем сайте здесь.
Использование JNDI для получения DataSource в java-приложении
Использование JNDI в программе, как правило, ограничивается всего несколькими строками. Типичным таким примером является подключение к серверу БД с использованием DataSource. Следующий код позволяет подключиться к источнику данных, привязанному к имени «java:jboss/datasources/slon». Этот источник данных определен в JBoss, и ниже будет показано, как его настроить.
Работа с JNDI всегда начинается с создания объекта InitialContext (или InitialDirContext в случае работы со службой каталогов). Конструктор этого объекта может принимать параметры, определяющие, к какой службе и каким образом подключаться. В данном случае параметры в конструктор не передаются, поэтому происходит подключение к службе имен сервера JBoss. Затем вызовом метода lookup() из службы имен извлекается объект DataSource, соответствующий имени «java:jboss/datasources/slon».
Класс DataSource предоставляет соединение с сервером БД в виде класса, реализующего интерфейс java.sql.Connection. То есть, DataSource управляет соединением с базой данных.
Какие преимущества даёт использование DataSource? Основное, что мы видим, так это отсутствие параметров учетной записи (login/password) и сервера БД (host, port). То есть, разработчики могут отлаживаться на тестовом сервере, а на рабочем сервере Заказчика WEB-приложение разместит уже знающий администратор/специалист.
Настройка DataSource в JBoss
Для настройки DataSource в JBOSS необходимо проделать 3 шага :
Параметры настройки DataSource :
После старта JBoss (сервер Oracle также запущен) в консоли должна появиться следующая информация :
Datasource java что это
Изучение интерфейсов DataSource и ConnectionPoolDataSource.
Оба интерфейса входят в пакет javax.sql и должны быть реализованы поставщиками JDBC классов (драйверов). Основное назначение интерфейсов DataSource и ConnectionPoolDataSource состои в предоставлении возможности получения соединения с базой данных абстрагируясь от местоположения сервера СУБД и типа драйвера конкретного производителя. Интерфейсы определяют ряд обязательных для реализации методов, в том числе и метод getConnection(). Объекты, получаемые от реализации данных интерфейсов используются для задания параметров соединения с базой данных и установки соединения в виде объекта типа Connection.
JDBC DataSource объекты используются для получения физического соединения с базой данных и являются альтернативой DriverManager. При этом нет необходимости регистрировать драйвер. Необходимо только установить соответствующие параметры для установки соединения и выполнить метод getConnection(). При создании объекта типа DataSource локально (прямо в приложении) параметры соединения задаются соответствующими методами, предусмотренными поставщиком драйвера. Эти методы не определены интерфейсом DataSource, т.к. параметры для соединения с СУБД разных производителей могут отличаться как по типу, так и по количеству (например, не для всех СУБД необходимо указывать тип драйвера или сетевой протокол). Так при работе с СУБД Oracle для использования соответствующих set и get методов необходимо получить объект типа OracleDataSource, который является экземпляром одноименного класса, реализующего интерфейс DataSource. В следствии этого такой способ создания объектов типа DataSource делает программный код менее мобильным и зависимым от конкретной реализации драйвера. Ниже приведен пример программного кода, иллюстрирующий локальное использование объектов типа DataSource.
Полностью возможности объектов типа DataSource проявляются в сочетании с использованием интерфейса JNDI. Использование службы имен и каталогов позволяет хранить заранее созданные системным администратором объекты типа DataSource с предустановленными параметрами соединения. Ниже приведены некоторые стандартные имена свойств (параметров), разработанные компанией Sun:
Комбинирование интерфейсов DataSource и JNDI играет ключевую роль в разработке многоуровневых корпоративных приложений, основанных на компонентной технологии J2EE. В случае использования комбинации интерфейсов DataSource и JNDI в программном коде приложения необходимо только затребовать объект типа DataSource у службы имен и каталогов. При этом детали соединения и зависимый от конкретной реализации драйвера программный код оказывается скрытым от приложения в хранящемся в службе имен и каталогов объекте.
Таким образом, совместное использование объектов типа DataSource и JNDI предполагает наличие двух выполняемых независимо друг от друга шагов:
1. Необходимо сохранить именованный объект типа DataSource в службе имен и каталогов, используя метод Context.bind() пакета javax.naming.
2. Затребовать в приложении объект типа DataSource у службы имен и каталогов, использую метод Context.lookup(). После чего можно использовать его метод DataSource.getConnection() для получения соединения с базой данных.
Ниже приведен пример совместного использования интерфейса JNDI и объекта типа OracleDataSource. В качестве службы имен и каталогов используется файловая система и необходимый для этого SPI (fscontext.jar и providerutil.jar).
Приложение начинается с инициализации объекта типа InitialContext, который открывает соединение со службой имен и каталогов, задает начальный контекст (начальный каталог дерева хранения объектов) и используется для загрузки объекта типа DataSource. Далее используется метод bindDataSource() для сохранения объекта типа DataSource в службе имен и каталогов.
Для демонстрации работы с сохраненным объектом создается переменная ds типа DataSource. Полиморфизм позволяет назначать ей экземпляры любых классов, реализующих интерфейс DataSource, в нашем случае это объект типа OracleDataSource. Метод lookup() запрашивает сохраненный объект типа OracleDataSource и возвращает результат типа Object, по этому его надо преобразовать в тип DataSource. Получив требуемый объект типа DataSource можно использовать его метод getConnection() для получения соединения с базой данных.
Объекты типа ConnectionPoolDataSource используются для получения объектов типа PooledConnection, которые представляют физическое соединение с базой данных и являются поставщиками объектов типа Connection. Сам по себе интерфейс PooledConnection не предусматривает методов для создания объектов типа Statement, по этому необходимо использовать объекты типа Connection.
Объекты типа Connection, получаемые с помощью объектов типа PooledConnection представляют логическое соединение с базой данных. Они выполняют те же функции, что и объекты типа Connection, получаемые с использованием интерфейса DriverManager. Они используюся для создания объектов типа Statement, PrepareStatement или CollableStatement, и управляют уровнем транзакций. Однако, метод close() таких объектов не закрывает соединение с базой данных, а возвращает объект логического соединения обратно в пул для повторного использования его другими клиентами.
Ниже приведен пример использования локального объекта типа ConnectionPoolDataSource, требующего установки параметров соединения в программном коде приложения.
В примере создается объект pc_1 типа PooledConnection для поставки объектов типа Connection. Далее создаются два логических соединения conn_1 и conn_2. После их создания выводится количество физических соединения. Физическое соединение одно, не смотря на наличие двух открытых логических соединений. При создании второго объекта pc_2 типа PooledConnection физических соединений становится два.
Изучение использования объекта типа ConnectionPool DataSource с предустановленными параметрами в комбинации с интерфейсом JNDI выносится на самостоятельную проработку.
Соединение с Объектами DataSource
Этот раздел покрытия DataSource объекты, которые являются привилегированными средствами получения соединения с источником данных. В дополнение к их другим преимуществам, которые будут объяснены позже, DataSource объекты могут обеспечить объединение в пул соединения и распределенные транзакции. Эта функциональность важна для вычислений базы данных предприятия. В частности это является неотъемлемой частью Предприятия JavaBeans (EJB) технология.
Этот раздел показывает Вам, как получить соединение, используя DataSource взаимодействуйте через интерфейс и как использовать объединение в пул соединения и распределенные транзакции. Оба из них включают очень немного изменений кода в Ваше приложение JDBC.
Работа, выполняемая, чтобы развернуть классы, которые делают эти операции возможными, который системный администратор обычно делает с инструментом (таким как Tomcat Apache или Oracle Сервер WebLogic), меняется в зависимости от типа DataSource объект, который развертывается. В результате большая часть этого раздела посвящается показу, как системный администратор устанавливает среду так, чтобы программисты могли использовать a DataSource объект получить соединения.
Следующие темы затрагиваются:
Используя DataSource Возражает, чтобы Получить Соединение
В Установлении Соединения Вы изучили, как получить соединение, используя DriverManager class. Этот раздел показывает Вам, как использовать a DataSource объект получить соединение с Вашим источником данных, который является привилегированным путем.
Объекты, которые инстанцируют классы, которые реализуют DataSource представьте определенный DBMS или некоторый другой источник данных, такой как файл. A DataSource объект представляет определенный DBMS или некоторый другой источник данных, такой как файл. Если компания будет использовать больше чем один источник данных, то она развернет отдельное DataSource объект для каждого из них. DataSource интерфейс реализуется поставщиком драйвера. Это может быть реализовано тремя различными способами:
A DataSource class, который поддерживает распределенные транзакции обычно также, реализует поддержку объединения в пул соединения. Например, a DataSource class, обеспеченный поставщиком EJB почти всегда, поддерживает и объединение в пул соединения и распределенные транзакции.
Предположите, что владелец процветающей цепочки магазинов Перерыва на кофе, от предыдущих примеров, решил расшириться далее, продавая кофе по Интернету. С большим количеством онлайнового ожидаемого бизнеса владелец будет определенно нуждаться в объединении в пул соединения. Открытие и заключительные соединения включает много издержек, и владелец ожидает, что эта система заказа онлайн требует значительного числа запросов и обновлений. С объединением в пул соединения пул соединений может использоваться много раз, избегая расхода создания нового соединения для каждого доступа к базе данных. Кроме того, у владельца теперь есть второй DBMS, который содержит данные для недавно полученной компании жаренья кофе. Это означает, что владелец будет хотеть быть в состоянии записать распределенные транзакции, которые используют и старый сервер DBMS и новый.
Цепочечный владелец реконфигурировал компьютерную систему, чтобы служить новой, большей клиентской базе. Владелец купил новый драйвер JDBC и сервер приложений EJB, который работает с ним, чтобы быть в состоянии использовать распределенные транзакции и получить увеличенную производительность, которая идет с объединением в пул соединения. Много драйверов JDBC доступны, которые являются совместимыми с недавно купленным сервером EJB. У владельца теперь есть трехуровневая архитектура с новым сервером приложений EJB и драйвером JDBC в среднем уровне и двух серверах DBMS как третий уровень. Клиентские компьютеры, обращающиеся с просьбами, являются первым уровнем.
Развертывание Основных Объектов DataSource
Системный администратор должен развернуться DataSource объекты так, чтобы команда программистов Перерыва на кофе могла начать использовать их. Развертывание a DataSource объект состоит из трех задач:
Во-первых, рассмотрите самый основной случай, который должен использовать основную реализацию DataSource интерфейс, то есть, тот, который не поддерживает объединение в пул соединения или распределенные транзакции. В этом случае есть только один DataSource возразите что потребности, которые будут развернуты. Основная реализация DataSource производит тот же самый вид соединений что DriverManager class производит.
Создание Экземпляра Класса DataSource и Установка его Свойств
Регистрация Объекта DataSource с Именованием Службы, Которая Использует API JNDI
С набором свойств системный администратор может зарегистрироваться BasicDataSource объект с JNDI (Именование Java и Интерфейс Каталога) именование службы. Определенная служба именования, которая используется, обычно определяется системным свойством, которое не показывают здесь. Следующая выборка кода регистрируется BasicDataSource возразите и связывает это с логическим именем jdbc/billingDB :
Используя Развернутый Объект DataSource
Переменная ds экземпляр class com.dbaccess.BasicDataSource это реализует DataSource интерфейс. Вызов метода ds.getConnection производит соединение с CUSTOMER_ACCOUNTS база данных.
getConnection метод требует только имени пользователя и пароля потому что переменная ds имеет остальную часть информации, необходимой для того, чтобы установить соединение с CUSTOMER_ACCOUNTS база данных, такая как имя базы данных и расположение, в его свойствах.
Преимущества Объектов DataSource
Из-за его свойств, a DataSource объект является лучшей альтернативой чем DriverManager class для того, чтобы получить соединение. Программисты больше не должны трудно кодировать имя драйвера или URL JDBC в их приложениях, который делает их более переносимыми. Кроме того, DataSource свойства делают код поддержания намного более простым. Если есть изменение, системный администратор может обновить свойства источника данных и не быть обеспокоен изменением каждого приложения, которое делает соединение с источником данных. Например, если бы источник данных был перемещен в различный сервер, то весь системный администратор должен был бы сделать, устанавливается serverName свойство к новому имени сервера.
Кроме мобильности и непринужденности обслуживания, используя a DataSource объект получить соединения может предложить другие преимущества. Когда DataSource интерфейс реализуется, чтобы работать с a ConnectionPoolDataSource реализация, все соединения производятся экземплярами этого DataSource class автоматически будет объединенными в пул соединениями. Точно так же, когда DataSource реализация реализуется, чтобы работать с XADataSource class, все соединения это, продукты автоматически будут соединениями, которые могут использоваться в распределенной транзакции. Следующий раздел показывает, как развернуть эти типы DataSource реализации.
Развертывание Других Реализаций DataSource
С ConnectionPoolDataSource и DataSource объекты развертывались, можно вызвать метод DataSource.getConnection на DataSource возразите и получите объединенное в пул соединение. Это соединение будет к источнику данных, определенному в ConnectionPoolDataSource свойства объекта.
Следующий пример описывает, как системный администратор для Перерыва на кофе развернул бы a DataSource объект, реализованный, чтобы обеспечить объединенные в пул соединения. Системный администратор обычно использовал бы инструмент развертывания, таким образом, фрагменты кода, показанные в этом разделе, являются кодом, который выполнил бы инструмент развертывания.
ConnectionPoolDataSource объект должен быть развернут сначала. Следующий код создает экземпляр com.dbaccess.ConnectionPoolDS и устанавливает его свойства:
Следующий код, который был бы, вероятно, выполнен инструментом развертывания, создает a PooledDataSource объект, устанавливает свои свойства, и связывает это с логическим именем jdbc/fastCoffeeDB :
Получение и Используя Объединенные в пул Соединения
Пул соединения является кэшем объектов соединения с базой данных. Объекты представляют физические соединения с базой данных, которые могут использоваться приложением, чтобы соединиться с базой данных. Во время выполнения приложение запрашивает соединение от пула. Если пул содержит соединение, которое может удовлетворить запрос, он возвращает соединение с приложением. Если никакие соединения не находятся, новое соединение создается и возвращается к приложению. Приложение использует соединение, чтобы выполнить некоторую работу над базой данных и затем возвращает объект назад пулу. Соединение тогда доступно для следующего запроса соединения.
Пулы соединения способствуют повторному использованию объектов соединения и уменьшают число раз, что объекты соединения создаются. Пулы соединения значительно улучшают производительность для интенсивных базой данных приложений, потому что создание объектов соединения является дорогостоящим и с точки зрения времени и с точки зрения ресурсов.
Теперь, когда они DataSource и ConnectionPoolDataSource объекты развертываются, программист может использовать DataSource объект получить объединенное в пул соединение. Код для того, чтобы получить объединенное в пул соединение точно так же как код для того, чтобы получить необъединенное в пул соединение, как показано в следующих двух строках:
Объединение в пул соединения обычно прозрачно программисту. Есть только две вещи, которые Вы должны сделать, когда Вы используете объединенные в пул соединения:
Используйте a DataSource возразите, а не DriverManager class, чтобы получить соединение. В следующей строке кода, ds a DataSource объект, реализованный и развернутый так, чтобы это создало объединенные в пул соединения и username и password переменные, которые представляют учетные данные пользователя, у которого есть доступ к базе данных:
Используйте a finally оператор, чтобы закрыть объединенное в пул соединение. Следующий finally блок появился бы после try/catch блок, который применяется к коду, в котором использовалось объединенное в пул соединение:
Иначе, приложение, используя объединенное в пул соединение идентично приложению, используя регулярное соединение. Единственная другая вещь, которую мог бы заметить прикладной программист, когда объединение в пул соединения делается, состоит в том, что производительность лучше.
Следующий пример кода получает a DataSource объект, который производит соединения с базой данных COFFEEBREAK и использование это, чтобы обновить цену в таблице COFFEES :
Соединение в этом примере кода участвует в объединении в пул соединения, потому что следующее является истиной:
Отметьте, что, хотя этот код очень подобен, чтобы кодировать Вас, видели прежде, это отличается следующими способами:
DataSource и ConnectionPoolDataSource интерфейсы находятся в javax.sql пакет, и конструктор JNDI InitialContext и метод Context.lookup часть javax.naming пакет. Этот определенный пример кода находится в форме компонента EJB, который использует API от javax.ejb пакет. Цель этого примера состоит в том, чтобы показать, что Вы используете объединенное в пул соединение тем же самым путем, Вы используете необъединенное в пул соединение, таким образом, Вы не должны волноваться о понимании API EJB.
Это использует a DataSource объект получить соединение вместо того, чтобы использовать DriverManager средство.
Это использует a finally блок, чтобы гарантировать, что соединение закрывается.
Получение и использование объединенного в пул соединения подобны получению и использованию регулярного соединения. Когда кто-то действующий как системный администратор развернул a ConnectionPoolDataSource объект и a DataSource возразите должным образом, приложение использует это DataSource объект получить объединенное в пул соединение. Приложение должно, однако, использовать a finally блокируйте, чтобы закрыть объединенное в пул соединение. Для простоты, предыдущий пример используемый a finally блок, но нет catch блок. Если исключение выдается методом в try блок, это будет брошено по умолчанию, и finally пункт будет выполняться в любом случае.
Развертывание Распределенных транзакций
DataSource объекты могут быть развернуты, чтобы получить соединения, которые могут использоваться в распределенных транзакциях. Как с объединением в пул соединения, должны быть развернуты два различных экземпляра class: XADataSource объект и a DataSource объект, который реализуется, чтобы работать с этим.
XADataSource объект должен быть развернут сначала. Следующий код создает экземпляр com.dbaccess.XATransactionalDS и устанавливает его свойства:
Теперь, когда экземпляры классов com.applogic.TransactionalDS и com.dbaccess.XATransactionalDS были развернуты, приложение может вызвать метод getConnection на экземплярах TransactionalDS class, чтобы получить соединение с COFFEEBREAK база данных, которая может использоваться в распределенных транзакциях.
Используя Соединения для Распределенных транзакций
Получить соединение, которое может использоваться для распределенных транзакций, должно использовать a DataSource объект, который был должным образом реализован и развернут, как показано в разделе, Развертывающем Распределенные транзакции. С таким DataSource объект, вызовите метод getConnection на этом. После того, как у Вас есть соединение, используйте его, как Вы использовали бы любое другое соединение. Поскольку jdbc/distCoffeesDB был связан с XADataSource объект в JNDI именование службы, следующий код производит a Connection объект, который может использоваться в распределенных транзакциях:
Для следующего примера предположите, что заказ кофе был доставлен, который инициировал обновления к двум таблицам, которые находятся на различных серверах DBMS. Первая таблица является новым INVENTORY таблица, и второе COFFEES таблица. Поскольку эти таблицы находятся на различных серверах DBMS, транзакция, которая включает их обоих, будет распределенной транзакцией. Код в следующем примере, который получает соединение, обновляет COFFEES таблица, и завершения соединение, являются второй частью распределенной транзакции.
Отметьте, что код явно не фиксирует или откатывает обновления, потому что контекстом распределенной транзакции управляет базовая системная инфраструктура сервера среднего уровня. Кроме того, предполагая, что соединение, используемое для распределенной транзакции, является объединенным в пул соединением, приложение использует a finally блокируйте, чтобы закрыть соединение. Это гарантирует, что допустимое соединение будет закрыто, даже если исключение будет выдано, таким образом гарантируя, что соединение возвращается к пулу соединения, который будет переработан.
Connecting with DataSource Objects
This section covers DataSource objects, which are the preferred means of getting a connection to a data source. In addition to their other advantages, which will be explained later, DataSource objects can provide connection pooling and distributed transactions. This functionality is essential for enterprise database computing. In particular, it is integral to Enterprise JavaBeans (EJB) technology.
This section shows you how to get a connection using the DataSource interface and how to use distributed transactions and connection pooling. Both of these involve very few code changes in your JDBC application.
The work performed to deploy the classes that make these operations possible, which a system administrator usually does with a tool (such as Apache Tomcat or Oracle WebLogic Server), varies with the type of DataSource object that is being deployed. As a result, most of this section is devoted to showing how a system administrator sets up the environment so that programmers can use a DataSource object to get connections.
The following topics are covered:
Using DataSource Objects to Get a Connection
In Establishing a Connection, you learned how to get a connection using the DriverManager class. This section shows you how to use a DataSource object to get a connection to your data source, which is the preferred way.
Objects instantiated by classes that implement the DataSource represent a particular DBMS or some other data source, such as a file. A DataSource object represents a particular DBMS or some other data source, such as a file. If a company uses more than one data source, it will deploy a separate DataSource object for each of them. The DataSource interface is implemented by a driver vendor. It can be implemented in three different ways:
A DataSource class that supports distributed transactions typically also implements support for connection pooling. For example, a DataSource class provided by an EJB vendor almost always supports both connection pooling and distributed transactions.
Suppose that the owner of the thriving chain of The Coffee Break shops, from the previous examples, has decided to expand further by selling coffee over the Internet. With the large amount of online business expected, the owner will definitely need connection pooling. Opening and closing connections involves a great deal of overhead, and the owner anticipates that this online ordering system will necessitate a sizable number of queries and updates. With connection pooling, a pool of connections can be used over and over again, avoiding the expense of creating a new connection for every database access. In addition, the owner now has a second DBMS that contains data for the recently acquired coffee roasting company. This means that the owner will want to be able to write distributed transactions that use both the old DBMS server and the new one.
The chain owner has reconfigured the computer system to serve the new, larger customer base. The owner has purchased the most recent JDBC driver and an EJB application server that works with it to be able to use distributed transactions and get the increased performance that comes with connection pooling. Many JDBC drivers are available that are compatible with the recently purchased EJB server. The owner now has a three-tier architecture, with a new EJB application server and JDBC driver in the middle tier and the two DBMS servers as the third tier. Client computers making requests are the first tier.
Deploying Basic DataSource Objects
The system administrator needs to deploy DataSource objects so that The Coffee Break’s programming team can start using them. Deploying a DataSource object consists of three tasks:
First, consider the most basic case, which is to use a basic implementation of the DataSource interface, that is, one that does not support connection pooling or distributed transactions. In this case there is only one DataSource object that needs to be deployed. A basic implementation of DataSource produces the same kind of connections that the DriverManager class produces.
Creating Instance of DataSource Class and Setting its Properties
Registering DataSource Object with Naming Service That Uses JNDI API
With the properties set, the system administrator can register the BasicDataSource object with a JNDI (Java Naming and Directory Interface) naming service. The particular naming service that is used is usually determined by a system property, which is not shown here. The following code excerpt registers the BasicDataSource object and binds it with the logical name jdbc/billingDB :
Using Deployed DataSource Object
The variable ds is an instance of the class com.dbaccess.BasicDataSource that implements the DataSource interface. Calling the method ds.getConnection produces a connection to the CUSTOMER_ACCOUNTS database.
The getConnection method requires only the user name and password because the variable ds has the rest of the information necessary for establishing a connection with the CUSTOMER_ACCOUNTS database, such as the database name and location, in its properties.
Advantages of DataSource Objects
Because of its properties, a DataSource object is a better alternative than the DriverManager class for getting a connection. Programmers no longer have to hard code the driver name or JDBC URL in their applications, which makes them more portable. Also, DataSource properties make maintaining code much simpler. If there is a change, the system administrator can update data source properties and not be concerned about changing every application that makes a connection to the data source. For example, if the data source were moved to a different server, all the system administrator would have to do is set the serverName property to the new server name.
Aside from portability and ease of maintenance, using a DataSource object to get connections can offer other advantages. When the DataSource interface is implemented to work with a ConnectionPoolDataSource implementation, all of the connections produced by instances of that DataSource class will automatically be pooled connections. Similarly, when the DataSource implementation is implemented to work with an XADataSource class, all of the connections it produces will automatically be connections that can be used in a distributed transaction. The next section shows how to deploy these types of DataSource implementations.
Deploying Other DataSource Implementations
With the ConnectionPoolDataSource and DataSource objects deployed, you can call the method DataSource.getConnection on the DataSource object and get a pooled connection. This connection will be to the data source specified in the ConnectionPoolDataSource object’s properties.
The following example describes how a system administrator for The Coffee Break would deploy a DataSource object implemented to provide pooled connections. The system administrator would typically use a deployment tool, so the code fragments shown in this section are the code that a deployment tool would execute.
The ConnectionPoolDataSource object must be deployed first. The following code creates an instance of com.dbaccess.ConnectionPoolDS and sets its properties:
The following code, which would probably be executed by a deployment tool, creates a PooledDataSource object, sets its properties, and binds it to the logical name jdbc/fastCoffeeDB :
Getting and Using Pooled Connections
A connection pool is a cache of database connection objects. The objects represent physical database connections that can be used by an application to connect to a database. At run time, the application requests a connection from the pool. If the pool contains a connection that can satisfy the request, it returns the connection to the application. If no connections are found, a new connection is created and returned to the application. The application uses the connection to perform some work on the database and then returns the object back to the pool. The connection is then available for the next connection request.
Connection pools promote the reuse of connection objects and reduce the number of times that connection objects are created. Connection pools significantly improve performance for database-intensive applications because creating connection objects is costly both in terms of time and resources.
Now that these DataSource and ConnectionPoolDataSource objects are deployed, a programmer can use the DataSource object to get a pooled connection. The code for getting a pooled connection is just like the code for getting a nonpooled connection, as shown in the following two lines:
Connection pooling is generally transparent to the programmer. There are only two things you need to do when you are using pooled connections:
Use a DataSource object rather than the DriverManager class to get a connection. In the following line of code, ds is a DataSource object implemented and deployed so that it will create pooled connections and username and password are variables that represent the credentials of the user that has access to the database:
Use a finally statement to close a pooled connection. The following finally block would appear after the try/catch block that applies to the code in which the pooled connection was used:
Otherwise, an application using a pooled connection is identical to an application using a regular connection. The only other thing an application programmer might notice when connection pooling is being done is that performance is better.
The following sample code gets a DataSource object that produces connections to the database COFFEEBREAK and uses it to update a price in the table COFFEES :
The connection in this code sample participates in connection pooling because the following are true:
Note that although this code is very similar to code you have seen before, it is different in the following ways:
The DataSource and ConnectionPoolDataSource interfaces are in the javax.sql package, and the JNDI constructor InitialContext and method Context.lookup are part of the javax.naming package. This particular example code is in the form of an EJB component that uses API from the javax.ejb package. The purpose of this example is to show that you use a pooled connection the same way you use a nonpooled connection, so you need not worry about understanding the EJB API.
It uses a DataSource object to get a connection instead of using the DriverManager facility.
It uses a finally block to ensure that the connection is closed.
Getting and using a pooled connection is similar to getting and using a regular connection. When someone acting as a system administrator has deployed a ConnectionPoolDataSource object and a DataSource object properly, an application uses that DataSource object to get a pooled connection. An application should, however, use a finally block to close the pooled connection. For simplicity, the preceding example used a finally block but no catch block. If an exception is thrown by a method in the try block, it will be thrown by default, and the finally clause will be executed in any case.
Deploying Distributed Transactions
DataSource objects can be deployed to get connections that can be used in distributed transactions. As with connection pooling, two different class instances must be deployed: an XADataSource object and a DataSource object that is implemented to work with it.
The XADataSource object must be deployed first. The following code creates an instance of com.dbaccess.XATransactionalDS and sets its properties:
Now that instances of the classes com.applogic.TransactionalDS and com.dbaccess.XATransactionalDS have been deployed, an application can call the method getConnection on instances of the TransactionalDS class to get a connection to the COFFEEBREAK database that can be used in distributed transactions.
Using Connections for Distributed Transactions
To get a connection that can be used for distributed transactions, must use a DataSource object that has been properly implemented and deployed, as shown in the section Deploying Distributed Transactions. With such a DataSource object, call the method getConnection on it. After you have the connection, use it just as you would use any other connection. Because jdbc/distCoffeesDB has been associated with an XADataSource object in a JNDI naming service, the following code produces a Connection object that can be used in distributed transactions:
For the following example, suppose that an order of coffee has been shipped, which triggers updates to two tables that reside on different DBMS servers. The first table is a new INVENTORY table, and the second is the COFFEES table. Because these tables are on different DBMS servers, a transaction that involves both of them will be a distributed transaction. The code in the following example, which obtains a connection, updates the COFFEES table, and closes the connection, is the second part of a distributed transaction.
Note that the code does not explicitly commit or roll back the updates because the scope of the distributed transaction is being controlled by the middle tier server’s underlying system infrastructure. Also, assuming that the connection used for the distributed transaction is a pooled connection, the application uses a finally block to close the connection. This guarantees that a valid connection will be closed even if an exception is thrown, thereby ensuring that the connection is returned to the connection pool to be recycled.