tag:blogger.com,1999:blog-5874979429188093780.post5718050287847781049..comments2024-03-18T06:46:54.352+01:00Comments on Andrej Baranovskij Blog: ADF Development Survival Kit - Essentials for ADF DeveloperAndrej Baranovskijhttp://www.blogger.com/profile/04468230464412457426noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-5874979429188093780.post-12304757264764401092013-12-08T13:37:48.023+01:002013-12-08T13:37:48.023+01:00Sounds good !Sounds good !Andrej Baranovskijhttps://www.blogger.com/profile/04468230464412457426noreply@blogger.comtag:blogger.com,1999:blog-5874979429188093780.post-34170140842797223922013-12-08T11:32:58.919+01:002013-12-08T11:32:58.919+01:00I added information about query execution times, f...I added information about query execution times, fetch size, range size (that are actually effective at runtime as they can be overridden at different levels: View Accessor config, VO instance in AM instance etc.)<br />to the common ADFbc base classes. <br />- Also information about the AM session<br />- Currently I log this to a separate Audit log which can be configured separately or turned off after the app has been sufficiently monitored. <br />- This should be easy to route it to a DB - for this I would use your LogManager technique (which I suppose would spawn a separate thread to write to DB to avoid interfering with the main request thread). <br />- I just do this preemptively - it's a new application. I think it's good practice to initially monitor this information and later turn it down/offJang-Vijay Singhhttps://www.blogger.com/profile/11926334117288628075noreply@blogger.com