The arguments against running webforms in a browser are for example:
- you loose part of the window because the browser menu, button bar, tab-pages, google searchbar, etc. all need space.
- using the back and refresh buttons on the browser closes the session (and data changes may be lost)

When your application runs in a separate browser window you still have this ‘empty’ browser window which may not be closed.

It’s too easy to say the users will have to adapt; so we looked for a different approach and found the following solution (although not supported by Oracle): Java Web Start.

With Java Web Start you can have
- a desktop icon to launch the application
- a separate application window
- jar-caching similar to using Jinitiator or the Sun Java plugin

Here is an example of a JNPL file:

<?xml version="1.0" encoding="utf-8"?>
<!-- JNLP File for testing Java Webstart -->
<jnlp codebase="http://[name of Oracle Application Server]:7777/forms/java” href=”DemoJavaWebStart.jnlp”>
<information>
<title>Oracle Forms Java Webstart Demo</title>
<vendor>LogicaCMG</vendor>
<description></description>
<description kind=”short”></description>
<offline-allowed/>
</information>

<applet-desc documentBase=”http://[name of Oracle Application Server]:7777/forms/java”
name=”OFJWD”
main-class=”oracle.forms.engine.Main”
width=”1020″
height=”710″>
<param name=”lookAndFeel” value=”Oracle”/>
<param name=”colorScheme” value=”Blue”/>
<param name=”width” value=”750″/>
<param name=”height” value=”600″/>
<param name=”serverURL” value=”/forms/lservlet?ifcfs=http://[name of Oracle Application Server]:7777/forms/frmservlet” />
<param name=”serverArgs” value=”escapeParams=true module=demo0000.fmx
sso_userid= sso_formsid= sso_subDN= sso_usrDN= debug=no host= port= buffer_records=no
debug_messages=no array=no obr=no query_only=no quiet=yes render=no
record= tracegroup= log= term=”/>
</applet-desc>
</jnlp>

Note that the security settings have all permissions set: <security><all-permissions/></security>. This is not without risk and requires all JAR files to be signed.

A second note is that jar-files added to the list with resources must be signed with the same certificate.
As the Oracle Forms jar “frmall.jar” is signed, other jar-files can not be simply added. However,
there is a workaround by calling a second jnlp-file from the resources tag. This jnlp-file contains
the additional resources that are needed.

<?xml version="1.0" encoding="utf-8"?>
<!-- JNLP File for testing Java Webstart -->
<jnlp codebase="http://[name of Oracle Application Server]:7777/forms/java” href=”FormsJars.jnlp”>

<resources>
<j2se version=”1.4+”/>
<jar href=”webstart.jar”/>
<jar href=”formsDemo.jar” />
<jar href=”webutil.jar”/>
</resources>
</jnlp>

The two jnlp-files are stored on the Oracle Application Server in the /java-directory.

We use Java Web Start to run Forms using client integration with Oracle WebUtil without problems.

But Java Web Start has its disadvantages too. As you need at least a URL on the client (for the first jnlp-file), now you have to start deploying client installations once again…

Now I’m part of the new UK Oracle Apps practice, I wanted to post a short update (or is this a ramble?) to you regarding the days sound bytes that I thought were note worthy.

Another very useful RAC SIG and networking day….

1. Julian Dyke, the chair, kicked off with the usual poll of attendees to find out who was running what version of what products, storage, OS’s etc etc : very interesting to hear about the ‘Product-ographics’ and the number of RAC nodes people get up to. 10gR2 RAC marches on…Notably there has been a decline in the number of 9iR2 RAC clusters replaced by 10gR2 clusters since June last year. Also quite a significant number of 11i installations running or about to be run in a RAC configuration. If anyone wants an insight into the popularity patterns of storage, products, OS’s , features choices please give me a shout.

2. Good update from Joel Goodman (Oracle ) and Phil Davies (Oracle) with patch updates. A few things to be aware of:- Oracle premium support for 9iR2 ends July 07 (Metalink Note: 189908.1). We should actively be suggesting upgrade programmes now or customers will have to pay an additional Extended Support fee (or perhaps accept that LCMG will no longer be able to guarantee SLA service levels on some contracts ?). Also be aware of the Daylight Saving Time patch for US timezone systems.

3. 10g Optional OEM Packs - Joel Goodman also gave a useful insight into the confusing (but feature rich) area of OEM pack licensing vagaries. Basically the only way to ensure you don’t accidentally use unlicensed packs is through the powerful 10g OEM GUI (not via the CLI !). The Service Level Management pack looks very interesting also. Also be aware the Oracle support may ask for AWR reports with out confirming you have a licensed Diagnostics Pack! I suggest we consider that all 10gR2 installations include, as a minimum, licensed OEM Database Control with Diagnostics pack?

4. Very interesting presentation by Andrew Stewart ( BetFair Ltd ) as to how there single 9i instance copes with 4-5 million bets per day. 75% of activity all just before each betting event. Interestingly they have discovered that Oracle RAC interconnect cache fusion looks like a better bet than MQ Series and also AQ (3x faster) for database messaging (Perhaps an unusual RAC usage concept but not that surprising?). A second look at RAC is on their agenda to reduce costs and remove SPoF. (Don’t think they have looked at Times Ten though?)

5. Bernhard de Cock Buning (Freelancer From NL) gave a nice insight into Oracle Clusterware components. The thing you need even if you use 3rd party clusterware for your 10g RAC installation. His emerging website is : http://www.rachelp.nl/

6. Troubleshooting Oracle E-Business Suite 11i on a 2 node Oracle 9iR2 stretched cluster : presented by me (Save the best till last!)

Key points here were:- use AutoConfig, shared APPL_TOP’s, be very careful to ensure Interconnect set-up OK and load balancing working at the TNS and Concurrent Manager levels, move to 10g2 RAC asap. You also cant get away without a separate RAC test cluster. DB’s who treat 11i on RAC like any other system will lead to erratic and potentially tearful results.

(Pretty pleased with response to this as the presentation was first ever repeat at the SIG and JulianDyke the chair (http://www.juliandyke.com) said it was the best 11i on RAC presentation he’d seen : I was pleased as he’s an Oak Table member.)

You can download most of the UKOUG presentations from

http://www.ukoug.co.uk/lib/ (ukmember/conference)

I hope you found this update interesting or even useful. Watch out for the next RAC SIG on 15th May in London.

Regards
Stuart Bensley

stuart.bensley@logicacmg.com
UKOUG RAC SIG Deputy chair.

My favorite application manager always wants me to increase the number of processes. For an app-server and for its end users it is bad publicity if ORA-00020 appears in a java-logfiles or even in front of a (web-based) customer (now who is to blame for that type of error handling ??). Hence the knee-jerk reaction to increase the "processes" parameter in the spfile. This demand is often accompanied by the assurance that the application will never (actively) use the high number of connections, but needs the high number to make very sure the error never will (re)appear. 

App-jockeys and managers generally refuse to take responsibility for setting or decreasing the upper-limit on the nr of connections in their JDBC connection pool. Some of the more exotic app-servers don’t even respect their own settings, and happily explode the nr of connections to something in the 4-digit range per app-server-instance.

Luckily, these app-servers will generally melt down by themselves, and that saves us from a database-brownout with more disastrous consequences. DCD or active killing then has to take care of the remaining connections, and preferably before the clusterware (automatically, unstoppable) or the operators (eager to stay within SLA) fire up the next application server who will also need to initiate his JDBC pool, hence needs the connections. 

However, if we are unlucky, the app-server doesn’t melt down, and the database hits the max-processes, whereby other app-servers with genuine need increase connections will also suffer. Not Good.And one reason why pools should be conservative in changing their number of connections.  

For the DBA, it makes sense to set the parameter to a value whereby the database can still operate "normally". Allowing too much processes, even inactive or near-dead ones, makes no sense and consumes unnecessary server-memory, sockets and cpu-cycles.Database and Unix zealots should now pop in and say that the processes-parameter controls many more derived values (transactions, sessions, enqueue_resources) and therefore requires careful consideration than just the shouting of the deployment team. I will stop there by saying: too high a setting is simply not beneficial. Vision the number of CPU’s in your system, and imagine the overhead of keeping a high number of processes alive, whether you use PGA and Workload parameters or not. (I can se a whole set of nerdy comments coming: Fine! As long as we agree on this: processes should be set lower, rather then higher, small is beautiful).  

In a legacy Client-server environment, it often makes sense to use shared-server or its predecessor MTS (Multi Threaded Server). The shared-server construct is ideal to handle a large load of relatively quiet connections. As the "clients" in C/S are often unaware of each others workload and existence, it is the database that needs to take on the job of sharing (pooling, queuing) the connections. Note that MTS or Shared-Server is equal to pooling connections on the database-server. Do we want the database-server to be busy juggling connections? (IMHO: only if we have no choice, but in C/S, the Shared server can make sense). 

In a J2EE environment, it makes more sense to use dedicated connections. Each call to the database should be handled Fast and the connection should be made available for the next thread that needs it.The database should ideally focus on doing its ACID task, and not be bothered with load- or connection-sharing. The Connection-pool can handle that. The JDBC pool mechanism is the component that should limit the number of connections and take care of the throttling. A JDBC pool should ideally open its maximum (=optimal) number of connections and keep those open, as the creation of a new connection takes time (when in a hurry, you can’t afford to wait for a new connection to be opened up). Provided the nr of processes (connections) is not allowed to go over a workable limit, there is no reason why each connection-pools should not be allowed to pre-create a fair number of connections. But the upper limit should be firmly set to a value where both the app- and the database server can still operate efficiently. 

Allowing too many connections under increasing load will result in degraded performance, and worse, in a meltdown of the instance. If that happens, everybody suffers, and not just the last-clicked-user. 

Two common causes for high numbers of connections are generally: 

1. Transactions take too long (performance or locking problems, improper use of XA), or
2. Connections not released back to the pool (sloppy coding or just plain bugs)

Therefore, it makes good sense to include connection-count and connection monitoring in the test-plans, and to monitor (count, plot) connections during live operations. My strategy is to always set processes to a conservative value. I use it protect my database against brownout and meltdown.It is up to the Java (or other app-level components) to use the number of available connections to the best extend, and to provide an error-handling or throttle-mechanism to handle overload.  

The approach in short: 

1. Determine how many connections the DB can server while maintaining reasonable response-times. 
2. Set that as max-processes. 
3. Tell your app-servers to stay within the limit (and use max-pool-size). 
4. Monitor the session-high-water limit (does it ever approach the max?) 
5. Do spot-counts of connections (and plot them over time) 
6. Audit-session to know where they come from (find the origin of high numbers). 

Bottom line: a surge in traffic should not be allowed to cause melt-down of the database. High volumes should be throttled higher up in the stack (load balancers, web-servers, app-containers).

If the throttling mechanisms are absent, or are not working then I think the database has a legitimate need to keep processes to a reasonable value. Potentially a difficult decision, but someone has to take it. Triage can be painfull, but there is a good reason to do it. The survival of the system can depend on it. 

Admittedly, this is a very db-centered  approach. Waiting for some debate from the app-guys now.