Cheese))) Как правильно?С dotConnect for Oracle Вы можете использовать любой из этих двух подходов, но при этом нужно учитывать особенности вашего окружения (время открытия коннекшина, стабильность подключения).

Cheese))) 1) Хранить сессию к ораклу в пользовательской сессииВы можете открыть коннекшин и держать его открытым в течении всей пользовательской сессии. При этом желательно реализовать логику ре-коннекта (а), если коннекшин оказался невалидным, либо валидировать коннекшин (б) перед очередным его использованием:
а) при работе через OCI (Oracle Client) можно использовать фичу Transparent Application Failover Support .
б) в директ режиме нужно обрабатывать эту ситуацию вручную - делать OracleConnection. Ping() (round-trip на сервер), и если соединение оказалось невалидным, открывать новое.

Cheese))) 2) Каждый раз в коде подключаться к ораклу, а драйвер (devart dotConnect for oracle) сам будет обрабатывать подключения и отдавать его через пулПредпочтительный способ коннекта для директ режима.
Принцип работы пулинга описан здесь . По умолчанию, Pooling=true. Если connection pooling включен и вызывается connection.Close(), коннекшин помещается в connection pool. Каждый коннекшин в пуле валидируется connection pooling manager-ом в параллельном потоке через 60 сек после открытия и потом каждые 30 сек. По умолчанию, connection не валидируется, когда он извлекается из пула. Т.е. возможна ситуация, когда приложение получит невалидный коннекшин из пула по connection.Open(). В этом случае Вы можете выставить дополнительную валидацию с коннекшин стринг параметром "Validate Connection=true" - и коннекшин будет валидироваться в момент извлечения из пула. Но.. используйте Validate Connection только в случае абсолютной необходимости, потому что его использование влечет дополнительный round-trip к серверу каждый раз при получении коннекшина из пула и, как следствие, потерю производительности.

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