Nested App Modules, Connection Pooling and Taskflow setup for Layered Enterprise ADF Application

[Ollyando]

Do I get an award for the longest title for a subject posted here? ;-)

Continuing on my posts of the project I am involved in, a 1000 Oracle
forms redesign to ADF. I thought I would post one of the issues we are
now facing on the project.

So far we have setup our project to follow presentations from Chris
Muir and Stan Vesterli and other members from this group.

Namely splitting the application up using the following structure.

Common Code Project
Common Model Project
Common View Project
Several BTF Projects for different modules
Master Consuming Project (using a customized version of the uishell
template to open btf's)

We are now well into our build phase, and apart from a few hiccups we
are progressing. However I am noticing issues with performance and
connection pooling.

Whilst testing some of the forms that the developers had created, I
noticed that after opening 15 forms based on btf's , the system
reported it could not open any more connections. Investigating the
weblogic server, I noticed that it had been left at the default setup
for connection pooling.

Okay no problem I just need to adjust the configuration parameters to
satisfy the demand of the concurrent users. Now looking into the
documentation from the fusion developers guide and posting from
Andrejus, Chris M, and others it seems this is quite a difficult
configuration with many moving parts.

1) Weblogic Connection Pool / Data source setup
2) App module parameters / config
3) Nested App Module setup
4) Bounded task flow setup

As far as I can see all these areas play a part on maintaining a
system that can handle the load / balance for our users.

Added to this, is the layered approach to the application and it
becomes rather complicated to work out.

So I wondered if someone has already done this hard work before, as a
lot of teams are using this layered application approach.

So far we have app modules at each level and project of the
application. I'm sure they should be nested to reduce the connections
to the database.

I wonder if we could come up with a standard approach on how to set
these things up if one does not already exists.

If a lot of shops are using this approach


Common Code Project
Common Model Project
Common View Project
Several BTF Projects for different modules
Master Consuming Project

What is the optimal setup say for 100 concurrent users.

Taking into consideration the following

1) Weblogic Connection Pool / Data source setup
2) App module parameter configuration
3) Nested App Module setup
4) Bounded task flow setup - reuse existing connection etc


Any takers?

Ollyando

[Rutwik Chandorkar]

One lesson that I have also learnt the hard way is that we should keep the number of root AMs to minimum, as each of them will have their own instance pool n each instance potentially latching to one db connection. The whole thing is replicate for each jvm.

Another trick here is to identify the usage patten for AM. Based on that u can have a AM with small pool size but with longer timeouts or AM with large pool size with shorter timeouts etc to better recycle your am instances n db connections.

While tuning the AM and connection pooling params, make sure that u have a separate data source tied to a almost unlimited conn pool for the AM activation/passivation operations. Coz if AM fails to perform activation/passivation because of constrained data source, u will start seeing data losses.

Hope this helps.

regards - rutwik

> --
> You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
>
> All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

[Chris Muir]

@Ollyando - sorry, the longest title award goes to some spammer who was putting the complete message text in the subject line. I blocked all those messages, but seriously was anyone interested in shares in a ponzi scheme?

Regarding the WLS default data source options, agreed the defaults are meaningless for an ADF application. If you use the UI Shell's multitab feature, where each tab uses a separate task flow with a separate transaction, you easily blow that limit. If Oracle ever comes out with a preconfigured VM containing a demo ADF application running on WLS, I bet we will see the data source options totally changed.

In discussing the issues of AMs in the architecture you may remember during my Angels in the Architecture presentation approximately slide 17 (http://sagecomputing.com.au/papers_presentations/ADF%20Architectural%20Patterns%20-%20LongBeach%20ODTUG%20minus%20pics.pptx) I said the issue of root vs nested AMs was worthy of another presentation, with the warning that getting this wrong will cause issues with your scalability, namely the number of database connections your app wants to take out. With this in mind, slide 17 showed 2 models of having a single root AM in the Common Model or a root AM per BTF application. If you take the later model, it's not possible to nest the BTF AMs under a single root AM at design time. Oh no I hear you say....

Luckily there's a number of solutions. Andrejus has one and you can see links at the end of my presentation that help you understand this. You won't be surprised to hear Andrejus has numerous other blog posts which are worth reading in this area too.

Another solution is built into framework itself if you use task flows.  You'll be aware that task flows depending on your transaction options can effect the number of AM pools & connections:

1) Prior to 11.1.2 at runtime ADF undertakes an automagical nesting of design time root AMs used by chained task flows, dropping the number of database connections & AM pools considerably. You can read an explanation of the behavior via the following blog entry: http://one-size-doesnt-fit-all.blogspot.com/2011/07/task-flows-sayonara-automated-nesting.html

I'm pecking this on my iPad so I'll save myself from describing the precise task flow options assuming you know them already. However if you don't please let me know and I'll write that up in a future post.

(Note the blog post mentioned above ends with a question how 11.1.2 implements the same nesting logic. I don't have a blog post to answer that but via helpful discussions with Oracle staff at OOW'11 and online, my understanding is as the following point...)

2) In 11.1.2.x the behavior has changed slightly. Database connections can be still conserved via the task flow options (ie. they're still shared), however all root AMs now get their own AM pools. In asking Oracle about this change, the response at the time was the trade off of extra AMs taking extra resources was worth it for the ability to tune each AM pool separately.  To be fair they also said they see the overhead of the AM pool itself is minimal, though I'm unclear how I would verify this point.

In returning to your original post with guidance on the 4 "moving parts";

1) As Rutwik says, set your WLS connections to the max & you'll probably never bother to configure this ever again
2) Agreed AM pooling config is still a concern though Andrejus blogged some good posts on configuring this recently
3) & 4) These should reduce to only 1 area of concern if you use the task flow transaction options

Hopefully this means we've reduced your concerns from 4 points to 2?!

Once I start with Oracle I'm hoping I'll have time to write a white paper on understanding the database connection issues vs all the configuration options. No promises but it's an area I enjoy working on and explaining.

CM.

[Steve Muench]

If you reference the two connection-related pooling settings that Andrejus blogs about here:

http://andrejusb.blogspot.com/2011/11/stress-testing-oracle-adf-bc_16.html

and if all your AM's use the same JDBC datasource, then your AM instances will share the single DB pool and only hang onto a connection for the duration of a single HTTP request. This should lead to dramatically fewer DB connections being used in practice, especially if you have many distinct AM pools.