Discussions
Categories
- 196.7K All Categories
- 2.2K Data
- 234 Big Data Appliance
- 1.9K Data Science
- 449.7K Databases
- 221.5K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 549 MySQL Community Space
- 477 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 532 SQLcl
- 4K SQL Developer Data Modeler
- 186.8K SQL & PL/SQL
- 21.2K SQL Developer
- 295.3K Development
- 17 Developer Projects
- 138 Programming Languages
- 292K Development Tools
- 104 DevOps
- 3.1K QA/Testing
- 645.9K Java
- 27 Java Learning Subscription
- 37K Database Connectivity
- 153 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 17 Java Essentials
- 157 Java 8 Questions
- 85.9K Java Programming
- 79 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.2K Java SE
- 13.8K Java Security
- 203 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 387 LiveLabs
- 37 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.6K Other Languages
- 2.3K Chinese
- 170 Deutsche Oracle Community
- 1K Español
- 1.9K Japanese
- 230 Portuguese
Performance Issues - LOV from SharedAM

Jdev: 12.2.1.2
I am seeing an issue in our product where one of the LOV items responds really slow. This is not reproducible in lower environments.
The LOB is populated using a list binding based on a view accessor on a Shared Application Module View Instance. The code for View Accessor in View Object is as below (note that RowLevelBinds=false).
<ViewAccessor Name="DepartmentVA" ViewObjectName="com.myComp.app.model.vo.DepartmentView" AMUsageName="MySharedAppModuleAppInstance" ViewInstanceName="DeparmentVO" RowLevelBinds="false"/>
We are detecting this slowness in App Dynamics monitoring that shows that this one lov has taken 47.8 seconds due to a wait on thread.
FacesServlet.service:651(107 ms self time, 47904 ms total time) EmployeeVORowImpl.getAttrInvokeAccessor:1508(0 ms self time, 47496 ms total time) EmployeeVORowImpl$AttributesEnum$61.get:629(0 ms self time, 47496 ms total time) EmployeeVORowImpl.getDepartmentVA:1487(0 ms self time, 47496 ms total time) Object.wait:Unknown (47496 ms self time, 47496 ms total time)
I have searched the code exhaustively and ensured that this shared app module VO instance is not being iterated upon manually and is being accessed only via List of Values in View Objects.
Any suggestions on how this can be debugged or any pointers? Is "SharedInstance" property on the View Accessor useful in this regard or could this be
Answers
-
Timo Hahn Senior Principal Technical Consultant - Oracle ACE Director Member, Moderator Posts: 38,234 Red Diamond
From the description, I would say: yes.
It's a small change which you can easily test.
The only other way I see is to dig deeper into the timing, e.g. by setting the log level to finest. This should get you more output with more timings. I hope you'll find the part of the code which causes the loss of time.
Timo