Есть некий пул соединений, с которым работа происходит примерно следующим образом:



При этом у соединения можно выставлять всякие разные свойства, например:


А вопрос такой - какого поведения стоит ожидать от пула по умолчанию:
1. Будут ли сохранятся ли эти свойства у соединения, например, если я вдруг в каком то месте кода говорю, что соединение read only, то во всех других нужно заботиться, чтобы явно переключать этот флаг в false?
2. Или при каждом возврате обратно в пул возвращаются в исходные значения, таким образом всегда при получении соединения из пула можно ориентироваться на некие значения по умолчанию и не переживать, что какой то другой код мог их переключить в иное значение?

Или все вендоры, кто в лес, кто по дрова, везде по разному, или проверяй свой?

Если вдруг кому интересно, то для пула из IBM WAS7 экспериментальным путем установил следующее:
При получении соединения из пула оно всегда приходит, со значениями Connection.TRANSACTION_READ_COMMITTED и установленным AutoCommit, независимо от того, что с ним делали при предыдущем использовании. О чем он каждый раз честно рапортует в SystemOut:
LocalTranCoor W WLTC0033W: Resource %datasourcename% rolled back in cleanup of LocalTransactionContainment.

Дополнительно выяснил, что, как минимум для случаев работы с соединением в рамках потока обработки http запроса возврат соединения в пул происходит не в момент conn.close(), а в какой то другой, после завершения обработки запроса. Т.к. в случае если max размер пула установлен в 10, то на 11ой итерации из ds.getConnection/conn.close() все начинает висеть на ожидании соединения. Да и похоже сам вызов conn.close() совсем не обязателен, по окончании обработки http запроса оно само возвращается в пул.

Petro123just_vladimir

было б что интересного.
Все 3 трогать не рекомендуется.
Автокоммит выключить.
Бывают исключения). Но редко.
C учетом того, что readonly ни Oracle не умеет, ни сама WebSphere не поддерживает, то на него можно забить.
Уровень изоляции транзакции доступны только TRANSACTION_READ_COMMITTED и TRANSACTION_SERIALIZABLE, остальные не поддерживаются и в итоге действительно остается только автокоммит...

Petro123Т.е. я даже роллбэк не смогу сделать, он сам коммитит?
Ага, именно так, идея этой штуки в том, что в тривиальных случаях это избавляет от лишнего бойлерплейт кода. В целом согласен, что удобней иметь по умолчанию отключенным, но для новых соединений это явно оговорено в доке:
http://docs.oracle.com/javase/tutorial/jdbc/basics/transactions.html When a connection is created, it is in auto-commit mode. This means that each individual SQL statement is treated as a transaction and is automatically committed right after it is executed. (To be more precise, the default is for a SQL statement to be committed when it is completed, not when it is executed. A statement is completed when all of its result sets and update counts have been retrieved. In almost all cases, however, a statement is completed, and therefore committed, right after it is executed.)

chabapokjust_vladimirЕсли вдруг кому интересно, то для пула из IBM WAS7 экспериментальным путем установил следующее:
При получении соединения из пула оно всегда приходит, со значениями Connection.TRANSACTION_READ_COMMITTED и установленным AutoCommit, независимо от того, что с ним делали при предыдущем использовании.
Ну, нормалек! Наверняка оно еще где-то конфигурируется, и если надо, то можно подкрутить настройки по умолчанию, и будет отдавать то, что вы хотите.
Скорее всего да, но где то глубоко, либо через custom properties, но явно не где то на поверхности...


chabapokjust_vladimirДополнительно выяснил, что, как минимум для случаев работы с соединением в рамках потока обработки http запроса возврат соединения в пул происходит не в момент conn.close(), а в какой то другой, после завершения обработки запроса. Т.к. в случае если max размер пула установлен в 10, то на 11ой итерации из ds.getConnection/conn.close() все начинает висеть на ожидании соединения. Да и похоже сам вызов conn.close() совсем не обязателен, по окончании обработки http запроса оно само возвращается в пул.
Тут хз. Я не такой большой спец, но выглядит как вопрос, требующий проработки. Если бы у меня такое возникло, то мне казалось бы, что это какое-то странное поведение, и я бы пытался понять, что происходит.
Имхо, в целом понятно что происходит. Подозреваю, что если открыть новый поток и проделать тоже самое в нем, то там возврат в пул уже будет только по conn.close и сразу же, может даже проверю чуть позже.

Petro123,
просто у меня есть очень много read only обращений, причем таких, что вообще пофиг на всевозможные dirty read и т.д. в связи с чем закралась идея, а не попытаться ли мне с экономить на этом деле, но как оказалось все тлен, ни read only, ни read uncommited не поставить, а автокоммит вообще тут как то сбоку.

http://www-01.ibm.com/support/docview.wss?uid=swg21600078 There is no data source custom property for autoCommit. To set this property in WebSphere Application Server, you need to call setAutoCommit on the connection, as shown above.

Basil A. Sidorovjust_vladimirпросто у меня есть очень много read only обращенийНу так заберите одно соединение из пула и не возвращайте, ибо нефиг.
Идею не понял, в чем смысл? Как выяснилось это свойство все равно никем не поддерживается...

Basil A. Sidorov,
получить/вернуть соединение в пул ничего не стоит, особо не с экономишь на этом. Хотя в общем то у нас создается ThreadLocal переменная с соединением на каждый Request требующий работу с БД, думаю дополнительно тут больше ничего уже не отыграть...
Пока самое существенное, что удалось отыграть это изменение FetchSize, если заранее знаем, что предстоит фетчить много записей.