Friday 29 February 2008

Deploying Oracle ADF: What did I learn about caching

Our company's production application server is located at a site different than the one we do our development. Whenever we deployed a new application users were always complaining about long response times, but we usually blamed that on the network. When we moved away from jsps and started working with JSF pages things really got out of hand.

Response times took as much as 10 seconds when application pages where accessed via WAN, rising the user complaint level to maximum levels.

Additionally the network link appeared to be utilized below 80% and then application server response times as shown at OC4J administration website where much below 0.045 sec.

First thing we tried was to use Oracle's ADF Cache library as explained in Chapter 23 of the ADF Programmers guide for Forms/4GL Developers, without any success. To be precise the library was indeed incorporated into the application but the server response time was still as long as 9 or 10 seconds.

It was then when we asked for help from Oracle Support. So thanks to Kavintha we learned the following :

  • First thing we learned was that the problem was indeed related to caching. Every JSF page created using Oracle ADF utilizes a Javascript file named Common10_1_3_3_0.js with a file size of 120 KB. This is an external script referenced at every page. The problem was that this script was never cached so users had to download it every time causing the delays mentioned above. If this file -- and all related page images -- are cached, then the usual size of an ADF/JSF generated HTML code ranges between 1 and 2 KBytes.
    Enabling full caching options on the Oracle Apache Server can be done by uncommenting the # CacheNegotiatedDocs line of the httpd.conf file located in $ORACLE_HOME/Apache/Apache/conf.
  • Next thing was that if an application is protected by Single-Sign-On then in that case, no matter whether CacheNegotiatedDocs is commented out or not, Apache will always send no-cache headers practically undoing whatever the Apache configuration or the ADF Faces Cache library do.
    The way to allow caching for SSO protected applications is to modify mod_osso.conf located in $ORACLE_HOME/Apache/Apache/conf so the entry for each application looks like this :
            <Location /ProductionDelays>
                    OssoSendCacheHeaders off 
                    require valid-user
                    AuthType Basic
            </Location>
    
    More information about how to to disable the caching headers sent by SSO is available on Metalink note 226119.1. Also you may have a look at a one of my previous postings regarding using SSO which is available through here
  • Last thing we learned about this caching business was that when a JSF application is accessed via SSL, then again caching issues still apply. Firefox will disable caching by default whenever the user loads an https:// URL. IE on the other hand does cache SSL pages by default but this setting can change by a policy set by your system administrator. I realize that in this case Firefox uses the safest approach but unfortunately this will produce very poor results if ADF/JSF pages are to be accessed.
    Enabling disk caching of SSL pages in Firefox can be done by changing the value of the browser.cache.disk_cache_ssl parameter available from the about:config URL.
    IE on the other hand has an option called Do not save encrypted pages to disk available in the Security section of the Advanced internet properties tab. If you want IE to cache content from SSL pages this option must be unchecked.

Wednesday 27 February 2008

Changing the JDeveloper IDE font size

If you are like me and wish that the JDeveloper IDE displayed using a bigger font, then thanks to Khaled from Oracle support all you need to do is shut down JDeveloper, and then add a line like the following in the file ide.properties located in \jdev\system\oracle.jdeveloper.10.1.3.X.Y.

Ide.FontSize=14

Finally start JDeveloper and you are done.

Notes

  1. The actual X, Y values in the oracle.jdeveloper.10.1.3.X.Y may vary depending on your version of JDeveloper. In 10.1.3.3 X=41 and Y=57, while in 10.1.3.4 X=42 and Y = 70. Anyway the safest approach is to have a look at the Oracle IDE version in the versions tab of the JDev about box as show in the image below.
  2. Needless to say that the same goes for SQLDeveloper. The only difference is that he file to edit is located in ~/.sqldeveloper/system/oracle.sqldeveloper.1.2.1.3213. If using SQLDeveoper version 1.5 that comes with the new JDev11g look and feel then again the file chek is .sqldeveloper/system1.5.1.54.40/o.sqldeveloper.11.1.1.54.40/ide.properties.
  3. On Jdeveloper 11g the ide.properties file location is ~/.jdeveloper/system11.1.1.0.31.51.56/o.jdeveloper. Once more the actul path may be determined by looking at the Oracle IDE version from the about box.

Saturday 23 February 2008

Oracle 11g How to determine the database character set

This is only a quick note for something I keep forgetting. So to determine the oracle database character set use the following simple SQL statement.

   select *
      from v$nls_parameters
      where parameter='NLS_CHARACTERSET'

Monday 11 February 2008

Oracle 10g Killing open sesions

We have a client program that leaves lots of open sessions. These sessions take up server resources and we wanted to find a way to locate and kill them.

Thanks to Natasa Oikonomidou from Softworks who provided the code, I ended up with the following solution:

Create a the following procedure on the sys schema.

create or replace
PROCEDURE inactive_session_killer
IS
  now DATE;
BEGIN
  now := sysdate;
  FOR rec IN
    (SELECT sid,
       serial#,
       username,
       schemaname,
       osuser,
       terminal,
       machine,
       PROGRAM,
       status,
       type,
       saddr,
       logon_time,
       now - last_call_et / 86400 last_activity
     FROM v$session
     WHERE username = 'XXXXX'   -- user name of open session "leaver"
           AND type = 'USER')
  LOOP

    IF rec.last_activity <( now  - 8 / 24) THEN
      -- inactive for more than 8 hours
      -- you can keep a log table here: inserrt into ...
      EXECUTE IMMEDIATE 'alter system kill session ''' ||  
                                        rec.sid || ',' || 
                                        rec.serial#    || 
                                        ''' immediate';

    END IF;

  END LOOP;
END;

Using SQLPlus or SQL Developer execute the following

 
VARIABLE jobno number;
BEGIN
   DBMS_JOB.SUBMIT(:jobno, 'inactive_session_killer;', SYSDATE, 'SYSDATE + 1/24');    -- runs every hour
   commit;
END;

... and that does it.