[jboss-jira] [JBoss JIRA] Assigned: (JBAS-2635) Performance enhancements to JDBC2 CMP

Performance enhancements to JDBC2 CMP ------------------------------------- Key: JBAS-2635 URL: http://jira.jboss.com/jira/browse/JBAS-2635 Project: JBoss Application Server Issue Type: Patch Security Level: Public(Everyone can see) Components: CMP service Affects Versions: JBossAS-4.0.3 SP1 Environment: Linux/Windows Reporter: David Strong Assigned To: Alexey Loubyansky Priority: Optional Fix For: JBossAS-4.0.5.CR1 Attachments: jboss-jdbc2-patches.tar.gz Unisys Patches For JDBC2 Unisys have made some patches to four of the JDBC2 files: $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/bridge/JDBCCMPFieldBridge2.java $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/schema/EntityTable.java $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/schema/PartitionedTableCache.java $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/schema/TableCache.java All changes are tagged with /// UIS and some brief comments. Some changes have been made to JDBCCMPFieldBridge2.java and EntityTable.java to cache frequently used objects such as entity fields and primary keys. The majority of changes relate to the interaction between EntityTable.java, PartitionedTableCache.java and TableCache.java. Consider the following situation. An EJB requires a row from the database. EntityTable.java contains an inner View class. The View seems to be instantiated per transaction. The View is asked to locate the row in question. First, the View looks to an internal cache. If the row exists, it is returned. If not, PartitionedTableCache.java and then TableCache.java are used to determine if the row is in their cache. If the row exists, it is returned. If not, the View loads the row from the database and places it into its own cache. At the end of the transaction in question, the View flushes its cache into the TableCache.java cache. The next transaction along will get a new View and the process starts again. This mechanism is adequate if rows are being updated. In this case, TableCache.java will hold a clean copy of the row, the View will update a copy of the row and then copy it back to TableCache.java in the case of a commit or not in the case of a rollback. However, in the case of a read only transaction, there is a lot of wasted overhead with object creation and copies that don?t really need to occur. The UIS patches to EntityTable.java, PartitionedTableCache.java and TableCache.java provide a prototype that does not make excessive copies of objects when a bean is marked as read only. Another patch to this area allows rows, from read only tables, to be preloaded at startup time. This allows the code to access caches without locking them and does not require the row promotion logic within TableCache.java to be executed. This prototype should only be used for small, static tables. The patches are enabled when the <read-only-cache> and <pre-load-rows> elements appear in the jboss.xml file for a specific EJB. A sample jboss.xml file is shown below: <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE jboss PUBLIC "-//JBoss//DTD JBOSS 3.2//EN" "http://www.jboss.org/j2ee/dtd/jboss_3_2.dtd"> <jboss> <enterprise-beans> <entity> <ejb-name>SomeEJB</ejb-name> <configuration-name>SomeEJB</configuration-name> </entity> </enterprise-beans> <container-configurations> <container-configuration extends="Standard CMP 2.x EntityBean"> <container-name>SomeEJB</container-name> <container-invoker-conf> <Optimized>True</Optimized> </container-invoker-conf> <container-cache-conf> <cache-policy-conf> <min-capacity>100</min-capacity> <max-capacity>100</max-capacity> </cache-policy-conf> <cache-policy-conf-other> <partitions>1</partitions> <read-only-cache>true</read-only-cache> <pre-load-cache>true</pre-load-cache> </cache-policy-conf-other> </container-cache-conf> </container-configuration> </container-configurations> </jboss> Although the prototype code seems to work well ? we?ve observed a 20% improvement in throughput in some test cases as well as lower CPU usage, better response times, less garbage created - we believe a better scheme could be used for read only transactions of this nature. We will investigate the possibility of using a different View for read only transactions, possibly reusing the same View for all read only transactions. The intent would be to provide caching at the View level only, to further reduce the overhead of unnecessary objection creation and copies. Another area of further investigation would be focused on the use of common caches between related entities. At present, it looks like entity relationships cause the same tables to be cached by different instances of EntityTable.java.