oracle adf architecture tv - design - adf bc application module design


Real World ADF Design & Architecture Principles

ADF BC Application Module Design

15th Feb 2013 v1.0


Learning Objectives

•  At the end of this module you should be able to:

– Determine if you need to create multiple root Application Modules or can survive with one

– Understand when your architecture will mean you have multiple Application Modules regardless and how you avoid consuming too many database connections

–  Technique to future proof your application module design – When and why you should use shared application modules

Image: imagerymajestic/ FreeDigitalPhotos.net


Program Agenda

•  Root and Nested Application Modules •  Number of Root Application Modules •  Application Module Connection Sharing •  Future Proofing Application Module Design •  Shared Application Modules


Root Application Modules

•  Expose View Objects to the Binding layer and indirectly the View layer as the basis of what is displayed to the user

•  1 instance given to each user at runtime, unless “shared” •  Stateful

•  Design time configure one JDBC URL/JNDI DataSource

•  Connect to the database, by inference control database transactions

•  Each root AM has its own application module pool

Image: winnond/ FreeDigitalPhotos.net


Root vs Nested Application Modules

•  An application can have 1 or multiple root AMs –  Each root AM has its own database connection

and therefore transaction –  If you multiply this by the number of concurrent

users this can limit your scalability

•  AMs can be “nested” under “root” AMs to logical group VOs –  But only the “root” AM is responsible for

connections/transactions/AM pool –  Nested AMs delegate all such responsibilities to

their root AM

Image: IKunl/ FreeDigitalPhotos.net


Program Agenda



How many root AMs should your app have? •  Reasons to have multiple

root AMs, you want:

1.  Separate (> 1) transactions per user session

2.  Separate (> 1) data sources in your app (rare)

3.  Configure different tuning options dependent on VO usage exposed through the AM

4.  Modularization (cylinder pattern)



root AMs, you want:



3.  Configure different AM tuning options dependent on VO usage exposed through the AM


•  Traditionally in 10g the only approach was to create multiple root AMs

•  In 11g the “isolated” data control scope task flow option create separate instances of the same root AM for the same user

•  This feature may make the need for multiple root AMs redundant



root AMs, you want:





•  Arguably rare (but valid) requirement •  Still requires separate root AMs

configured to access the different data sources

•  Essential to use the <No Controller Transaction> task flow option otherwise the other task flow transaction options with a shared data control scope may consolidate the connection under the disparate AMs

•  (More discussed soon)



root AMs, you want:





•  Possibly taken care of by “shared” AMs •  Be aware of the “automagical” nesting

of AMs and task flow transaction options (besides <No Controller Transaction>) –  Under 11gR1 each root AM is nested under

the first task flow root AM –  Under 11gR2+ (inc 12c) each root AM

maintains itself as root with separate AM pools

–  http://bit.ly/automagicAMnest1 –  http://bit.ly/automagicAMnest2 –  http://bit.ly/automagicAMnest3



root AMs, you want:





•  The cylinder pattern proposes separate model layers for each cylinder

•  Allows large teams/developments to not have dependencies on each other

•  Not actually possible to nest AMs under a single root AM without creating an intermediary model layer to re-group AMs – this results in as many connections as root AMs

•  We can use the BTF transaction options to solve this (next section)


Program Agenda



Automatic ADF BC Root AM Connection Sharing

•  If an application contains multiple root AMs all connecting to same db –  Possibly forced upon the application architecture by breaking the application into

self contained BTF workspaces

•  A single page consuming multiple BTF workspaces will spawn a large amount of database connections seriously limiting scalability

•  If BTF transaction options are used (Not <No Controller Transaction>) –  ADF will automatically merge the AM connections –  Throws runtime error if the root AMs don’t share same JNDI

•  Radically reduces the number of connections


Automatic ADF BC Root AM Connection Sharing •  Validate this behavior by:

–  (With ADF Source Code) Place breakpoint on oracle.jbo.server.DBTransactionImpl.establishNewConnection()

–  Or watching connections at the db level: SELECT * FROM v$session WHERE username = 'HR';

–  Be mindful the BTF “No save point upon task flow entry” option when unselected may result in an extra internal connection

•  If you don’t want this behavior, for example: –  You need to separate data sources (different databases) –  Or you’re comfortable with the older 10.1.3 root AM design

•  Use <No Controller Transaction>


Automatic ADF BC Application Module Nesting

•  How this is achieved is through some trickery under the ADF BC covers

•  The implementation of this has changed between releases

•  Programmers can accidentally fall afoul in transitioning from 11gR1 to 11gR2 or 12c

•  11gR1 functionality commonly referred to “Automagical AM nesting”

Image: arztsamui / FreeDigitalPhotos.net


Automatic AM Nesting Behavior 11gR1 •  Behavior for 11gR1 (Pre 11.1.2) •  1st AM data control used becomes the master root AM of the data control frame •  Subsequent AM data controls within the same shared BTF chain will automatically

nest regardless under the master even if they’re defined as a root AM •  As there is only 1 root AM at runtime, only one AM pool will be required

–  Implies you do not need to tune the AM pool of every root AM –  Be careful that the root AM you think will become the master root AM does get

used first, otherwise a non tuned root AM will become the master •  As there is only 1 root AM the connection of the root AM data control is used for all

the nested AMs (the same as normal AM nesting behaviour) •  This highlights a limitation if the root AMs require different data sources, this

automatic behavior means this cannot be supported


Automatic AM Nesting Behavior 11gR2+

•  Behavior for 11.1.2+ (and 12c) •  All root AM data controls remain as root – there’s no automatic nesting •  Each root AM will have its own AM pool and can be tuned separately •  However the connection definition of the master root AM is used for all AMs

–  Limits database connections which is desired –  But the same limitation if the root AMs require different data sources, this

automatic behavior means this cannot be supported

19 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 19 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

Oracle is unlikely to change the behavior of the underlying connections as this would break the ability of

apps to scale....

....however Oracle reserves the right to change the implementation details. As such if you programmatically

walked the automatic nesting in 11gR1 for example, Oracle has changed the implementation such that your

code would now break in 11gR2+.

Image: Ambro / FreeDigitalPhotos.net


Program Agenda



For most of our applications a single root AM is satisfactory.

But what if we later realize we wanted some of the benefits of

multi-root AMs, how can we future proof our design?

Exercise



Best Practice – Pseudo root AMs

•  In most cases a single root AM is satisfactory •  Yet don’t dump all VOs under the single root AM

–  This will make it impossible to move to a multi-root AM model later if needed

•  Use the logical grouping of nested AMs to segment the VOs in your application (~pseudo root AMs)

•  As nested AMs also appear in the Data Control palette as root AMs, it’s a relatively simple task of rewiring the DataBindings.cpx to use the nested AM as a root if you decide this is necessary later on


Best Practice – Legacy Systems

•  Older systems may have already created multiple root AMs •  Arguably this may be by design (see previous reasons) •  But if accidental the app will be getting hit with the resource

overhead of multiple AM pools •  The pseudo root AMs fix will work here too

–  Create a new root AM and nest existing AMs –  Reconfigure DataBindings.cpx to use new root AM –  Test test test


Time for a challenge to see how well we know ADF Business Components.

For 1 user session we have mul=ple root AMs.

In defining business rules for EOs and LOVs for VOs in the 1st root AM, you want to access VOs via View

Accessors in the 2nd root AM.

How do we solve this?

Exercise #1



Another challenge

Typically ADF instan=ates one root AM instance per user session and creates VO instances per root AM.

This is fine for transac=onal data, but memory is wasted for read-‐only VOs, par=cularly for reference

data.

How do we solve this?

Exercise #2



Program Agenda



Shared Application Modules

•  ADF provides two types of Shared Application Modules: –  Session Level - VOs are shared across root

AMs of the same user –  Application Level - VOs are shared across

all user sessions

–  Configured via Model project properties – ADF Business Components – Application Module Instance options


How Shared is Shared?

•  "Session Level" Shared AMs –  An instance of the shared AM is nested under the root AM you wish to share with –  It is not shared by other root AMs or other users' sessions –  If you share the AM with 2 separate root AMs, 2 separate instances of the shared

AM are created with their own state –  In all manners acts just like a nested AM, sharing AM pool, connection and

transactions

•  "Application Level" Shared AMs –  At runtime an instance of the shared AM is created as a root AM in its own right –  Only one AM instance is created and shared by all user sessions –  Acts as a root AM with its own AM pool, a single connection and transaction


Application Level Shared AMs

•  To support multiple sessions using same VO –  Separate iterators are created for each session –  If VOs are parameterized, multiple row sets are also created per parameter set

and stored in a query collection –  e.g. For the following query

SELECT emp_id, name FROM employees WHERE dept_id = :deptIdVar ...run with values 10, 20, 30 and 40, 4 different query collections would be created

–  Number of query collections can become substantial


Application Level Shared AMs Tuning •  ADF BC pool monitor removes query collections on a timeout basis

–  jbo.qcpool.maxinactiveage (default 1800000 ms) –  jbo.qcpool.monitorsleepinterval (default 90000 ms)

•  To further restrict totals rows for each VO –  Pool monitor checks if total number of VO rows exceeds "maximum weight" –  If discovered query collections are ejected on LRU basis –  jbo.qcpool.maxweight (default -1 of no limit) –  Or can be set programatically for each VO by overriding the ViewObjectImpl initSharedQCPoolProperties()!

//In view object implementation class protected void initSharedQCPoolProperties(QCPoolProperties qcProp){ qcProp.setMaxWeight(10000); }


Using Shared AM Client Methods •  Client methods defined at the AM/VO/VO Row level are not

executed on the Shared AM –  At design time drag ‘n dropping these methods via Data Control Palette will create

configurations for normal AM instance, not the shared AM –  Instead you call shared AM methods via other normal AMs

•  Shared AM methods can read/write to VO state –  Avoid writes (such as updating current row indicators) as this will confuse other

users sharing the data

SharedModuleImpl am = (SharedModuleImpl) findOrCreateSharedApplicationModule( "SharedModuleInstance", "model.SharedModule", SHARED_SCOPE_APPLICATION); String result = am.sharedAppModuleMethod("someParameter");

Courtesy Avrom Roy-Faderman - http://www.avromroyfaderman.com/


Using Shared AM Client Methods

SharedModuleImpl am = (SharedModuleImpl) findOrCreateSharedApplicationModule( "SharedModuleInstance", "model.SharedModule", SHARED_SCOPE_APPLICATION); // Accessing View Object methods String result = am.getAllDepartments().sharedAppModuleVoMethod("someParameter");

Courtesy Avrom Roy-Faderman - http://www.avromroyfaderman.com/

•  Accessing View Object methods via a shared AM

•  Accessing View Object Row methods via a shared AM –  Creates alternative RowSetIterator so primary RSI row is not disturbed

// Accessing View Object Row methods RowSetIterator deptIterator = am.getAllDepartments.createRowSetIterator(null); DepartmentsViewRowImpl firstDept = (DepartmentsViewRowImpl)deptIterator.first(); deptIterator.closeRowSetIterator(); String result = firstDept.sharedAppModuleVoRowMethod("someParameter");


Conclusion

•  Though you can create multiple root AMs at design time, it's also possible through the combination of task flow features to create multiple root AM instances even if you only have 1 at design time

•  When working with root AMs, always remember the number of connections that are taken out, this will seriously affect your application's scalability

•  Consider shared AMs to take the memory burden of read only data off normal root AMs

oracle adf architecture tv - design - adf bc application module design

Technology

vo usage exposed

courtesy avrom roy

tuning options dependent

program agenda root

data control palette

btf transaction options

root ams require

multiple root ams