This chapter describes how to improve ADF Swing application runtime performance. It describes data synchronization techniques for optimum performance as well as a technique to limit fetching of ADF Business Components attributes in ADF Swing applications.
This chapter contains the following sections:
Section 10.1, "About Optimizing ADF Swing Application Runtime Performance"
Section 10.2, "How to Delay Updates to ADF Business Components from ADF Swing"
Section 10.3, "What You May Need to Know About the Sync Mode Property"
Section 10.4, "How to Limit Fetching of ADF Business Components Attributes in ADF Swing"
You can make method calls in your ADF Swing code to optimize the network traffic between the client and the ADF Business Components business services in remote deployment mode.
Users who work with the design time tools in JDeveloper will by default obtain the optimization described in this section.
However, you may need to perform these optimizations if you develop applications outside of JDeveloper using the provided APIs for ADF Business Components and do not use the JDeveloper design time to create the ADF Swing client.
You can improve network traffic at the expense of less frequent validation submitted by an ADF Business Components client application to the remotely deployed business components by setting the data synchronization mode of the ADF Business Components application module to batch. Batch mode means attribute value changes made by the user will be held on the client tier until the user performs an action that forces the changes to be submitted. Also known as lazy sync mode, batch mode will reduce the number of trips over the network, consequently validation of the attributes by ADF Business Components will be delayed.
The data synchronization is "immediate" mode by default which applies changes as soon as they are made and results in immediate validation of attribute values.
Note:
In local mode deployment (the client and ADF Business Components reside in the same VM), sync mode is always "immediate".
To change a client's synchronization setting within JDeveloper:
In the Applications window, change the display mode to Directory View, then expand the user interface project and select the DataBindings.cpx file.
The DataBindings.cpx file is added to the adfmsrc folder of your user interface project.
In the Structure window, expand dataControlUsages and select the desired data control.
In the Properties window, expand the Other section and select the desired setting from the syncMode field dropdown list.
To set the sync mode of an application module (outside of the JDeveloper design time):
Call setSyncMode() on the ApplicationModuleImpl class:
yourAm.setSyncMode(ApplicationModule.SYNC_IMMEDIATE);
You can set it to SYNC_IMMEDIATE when you want to maximize control of attribute validation by ADF Business Components at the expense of network optimization. For example, in this mode, if the client sets ten attributes of an employee, your code would call ten setAttribute() methods in order to provide validation for each new value.
Or
yourAm.setSyncMode(ApplicationModule.SYNC_LAZY);
You can set it to SYNC_LAZY to optimize your application by reducing the number of trips over the network. In this mode, the client-side attribute set requests are buffered until the next time the client sends an event to ADF Business Components, instead of when the data is changed. No further changes to your application code are required. For example, if the client sets ten attributes of an employee, your code would call the setAttribute() methods only after the client:
Changes the current row
Calls the postChanges() or commit() methods
Calls the sync method explicitly
Calls the validate() method on the row
If you are inside a class that extends ApplicationModuleImpl, because it implements the ApplicationModule interface, you can just add the code shown in Example 10-1.
Example 10-1 Code When Class Extends ApplicationModuleImpl
ApplicationModule yourAm = panelBinding.getApplication().getApplicationModule(); yourAm.setSyncMode(SYNC_LAZY);
However, if you are in another class (for example, in the client code), then you need to qualify the constant with the interface on which it appears, as shown in Example 10-2.
Example 10-2 Code When In Another Class
ApplicationModule yourAm = panelBinding.getApplication().getApplicationModule(); yourAm.setSyncMode(ApplicationModule.SYNC_LAZY);
You should call setSyncMode() in the ADF Swing bootstrap code, immediately after the data control object is created. Or, you can call getApplication() and set the sync mode in the constructor for your ADF Swing panel. The location you choose depends upon whether you want the sync mode to persist for the entire application or to be modified at the level of the panel.
If you decide to set data synchronization programmatically on the ApplicationModule, you should be aware of an interaction that will occur with the syncMode property setting on the ADF Business Components data control. Only the following three valid combinations exist.
am.setSyncMode(SYNC_IMMEDIATE) + syncMode property "Batch" -- yields Batch mode. All updates will be delayed until next am.sync(), which needs to be called by the application at an appropriate time by calling bindingContainer.refresh(). Alternatively, updates will occur automatically when Rollback and Commit actions are initiated.
The SYNC_IMMEDIATE +"Batch" combination is the default in JDeveloper 10.1.2 and later when you create an ADF BC project. This is the combination to use for 3-tier ADF Swing applications in JDeveloper 10.1.2 and later.
am.setSyncMode(SYNC_LAZY) + syncMode property "Immediate" -- yields Immediate mode and set attribute method calls will be delayed until the next row navigation.
The SYNC_LAZY +"Immediate" combination is the setting for ADF Swing 9.0.5 and earlier applications that are deployed in 3-tier mode and that you upgrade to 10.1.2 and later.
am.setSyncMode(SYNC_IMMEDIATE) + syncMode property "Immediate" -- yields Immediate mode.
The SYNC_IMMEDIATE +"Immediate" combination is appropriate for applications that have a very high level of interactivity with the database and/or where immediate validation is required. In this case the application should be run in immediate mode so that data is synchronized immediately. It is not recommended for ADF Swing applications.
Users who work with the design time tools in JDeveloper will by default obtain the optimization described in this section.
However, you may need to perform these optimizations if you develop applications outside of JDeveloper using the provided APIs for ADF Business Components and do not create view object metadata (XML files).
You can optimize startup time for an ADF Business Components client application and the remotely deployed business components by specifying the list of view object attributes that your client uses. If you create a project without the metadata, by coding to the API, you will want to add fetchAttributeProperties() to the bootstrap code of the client forms with a list of only the attributes used by the form. Without this method call, your client form would fetch all control hint properties (including the attributes format and label for example) for all the attributes of the named view objects in the application module, in a single network roundtrip.
For example, when you do not intend to use all the attributes of the ADF Swing form's bound view object, with the fetchAttributeProperties() method, your ADF Swing form fetches only the information required to layout your forms, while ignoring the attributes you do not require.
Note:
In local mode deployment (the client and ADF Business Components reside in the same VM), the fetching of attribute properties is not supported.
To minimize retrieving of attribute properties (outside of the JDeveloper design time):
Call fetchAttributeProperties() on the ApplicationModule:
The method takes as arguments a list of view object names and a list of attribute names for each view object. The lists may include all or some of the attributes. If your forms require all the attributes of a view object, you may specify null as the attribute argument. In this case, the startup time improvement may not be significant since your form uses all the attributes of the view object anyway.
Note:
When you use the ADF Swing Form or Panel wizards to generate complete forms, the fetchAttributeProperties() method is added for you.
You should call fetchAttributeProperties() in the ADF Swing bootstrap code, as shown in Example 10-3, immediately after the data control object is created. In the following example, the custom properties for three attributes of the first view object and five attributes of the second view object are downloaded.
Example 10-3 Calling fetchAttributeProperties in ADF Swing Bootstrap Code
// bootstrap application
JUMetaObjectManager.setBaseErrorHandler(new JUErrorHandlerDlg());
JUMetaObjectManager mgr = JUMetaObjectManager.getJUMom();
mgr.setADF SwingDefFactory(null);
BindingContext ctx = new BindingContext();
ctx.put(DataControlFactory.APP_PARAM_ENV_INFO, new JUEnvInfoProvider());
ctx.setLocaleContext(new DefLocaleContext(null));
HashMap map = new HashMap(4);
map.put(DataControlFactory.APP_PARAMS_BINDING_CONTEXT, ctx);
mgr.loadCpx("DataBindings.cpx", map);
DCDataControl app = (DCDataControl)ctx.get("model_AppModuleDataControl");
app.setClientApp(DCDataControl.JCLIENT);
app.getApplicationModule().fetchAttributeProperties(new String[]
{"VO1", "VO2"}, new String[][]
{
{"VO1Attr1", "VO1Attr2", "VO1Attr3"},
{"VO2Attr1", "VO2Attr2", "VO2Attr3", "VO2Attr4", "VO2Attr5"}
}, null);
...
Calling fetchAttributeProperties() prevents property methods such as getFormat() or getLabel() from being called on the ADF Business Components attribute definition whenever the form is created.