I will describe a case of leaking DB connections during ADF login phase. This case is reproduced for ADF application with Login screen and programmatic login action from managed bean. If you call ADF BC before calling ADF authentication servlet and doing authentication - no DB connection leaking. But if you call ADF authentication servlet first and then as next action call ADF BC in the same method - DB connection will remain active.
Download sample application which demonstrates this case - SecurityFormLogin_v6.zip. Sample is configured to use DB connection pooling for ADF, this means DB connection will be released after request is completed (read more here: Stress Testing Oracle ADF BC Applications - Do Connection Pooling and TXN Disconnect Level):
Temporary in memory store is enabled to keep data between requests, when DB connection is returned to the pool:
To test this sample application, login into:
ADF screen will be rendered after authentication is completed:
Here you can see source code of Login class, where I'm calling ADF BC before performing ADF authentication:
ADF BC call is done through ADF bindings:
In this case, when ADF BC logic is invoked before calling ADF authentication servlet - DB connection is used and immediately returned back to the pool:
Test now with ADF BC invocation just after calling ADF authentication in the same login method:
You will notice now - DB connection acquired by ADF BC from Login method, will not be returned back to the pool:
Imagine now, if the same behavior will be reproduced in production. This means if you support 500 concurrent users, they will reserve 500 DB connections. This may break your application, if DB connections max size is not large enough. My point is - test your application before going to production and monitor DB connection usage, this will help to have stable ADF application.
Download sample application which demonstrates this case - SecurityFormLogin_v6.zip. Sample is configured to use DB connection pooling for ADF, this means DB connection will be released after request is completed (read more here: Stress Testing Oracle ADF BC Applications - Do Connection Pooling and TXN Disconnect Level):
Temporary in memory store is enabled to keep data between requests, when DB connection is returned to the pool:
To test this sample application, login into:
ADF screen will be rendered after authentication is completed:
Here you can see source code of Login class, where I'm calling ADF BC before performing ADF authentication:
ADF BC call is done through ADF bindings:
In this case, when ADF BC logic is invoked before calling ADF authentication servlet - DB connection is used and immediately returned back to the pool:
Test now with ADF BC invocation just after calling ADF authentication in the same login method:
You will notice now - DB connection acquired by ADF BC from Login method, will not be returned back to the pool:
Imagine now, if the same behavior will be reproduced in production. This means if you support 500 concurrent users, they will reserve 500 DB connections. This may break your application, if DB connections max size is not large enough. My point is - test your application before going to production and monitor DB connection usage, this will help to have stable ADF application.
Great post Andrejus!
ReplyDeleteBut would a correct approach be in case you need to call ADF BC after authentication so that you don't have DB leakage?
You should call ADF BC before ADF authentication. If you set user preferences into session scope, data will be preserved even after authentication. So, there is no really reason to call ADF BC after authentication.
ReplyDeleteAndrejus
Hello Andrejus.
ReplyDeleteA link to testcase application is leading to 404. Could you reupload testcase by any possibility?
Thanks.
Hi,
ReplyDeleteAll samples prior 2014 are available in Google Archive, more here: http://andrejusb.blogspot.com/2017/08/my-blog-samples-download-repository-for.html
Andrej