Product Documentation

• The following resources are expensive and should be watched carefully
  
  
  • Database connections
  • Prepared statements
  • Result sets
• For any resource you use
  
  
  • After opening the resource, you must close it when you are finished with it
  • Resources should be initialized within a ‘’try’’ block
  • Resources should be closed or de-allocated within a ‘finally’ block.

Database Connections

• These are an expensive and finite resource
• Remember to close all connections you open, once your code has completed using them
• Failing to do so can lead to obscure problems “down the line”, when other processes run out of available connections in the available connection pool
• The number of connections and their time to live is controlled in the Configuration.properties file. This is an excerpt of the file with these settings –
  
  

  # Connection pool settings
  ConnectionPoolSize    = 10
  ConnectionPoolMax     = 200
  ConnectionUseCount    = 500
  ConnectionTimeout     = 10
  ConnectionPoolTimeout = 20

• Note that database connections should not use con.close
• Name the connection you open with the name of the method that opens the connection. This makes debugging using ConnectionPoolMon simpler as all connections using this name will be visible (all ExtraView connections are anonymous)
• Example -
  
  

  public void frSelectList(SesameSession session, ValidationList selList,  
  		String pGlobal, HashMap selectedVals, HashMap attributes)
    {
  
    // code removed for clarity
  
    try{  con = Z.pool.getConnection();
            sql = "select security_user_id, first_name || ' ' || 
                  last_name from security_user";
            pstmt = con.prepareStatement(sql);
            rs = pstmt.executeQuery();
            selList.put( "$$USER$$","* Current User Name *");
            while(rs.next()) {
                  selList.put( rs.getString(1), rs.getString(2));
            }
            pstmt.close();
          }
          catch(SQLException sqle) {
              Z.log.writeToLog(Z.log.ERROR, 
               "UserCustom.getAllowedValues SQLException: " + sql);
              ErrorWriter.write(sqle, ErrorWriter.LOGERR);
          }
          catch(Exception e){
              ErrorWriter.write(e, ErrorWriter.LOGERR);
          }
          finally{  if (con != null) Z.pool.close(con);
          }
        }
          return;
      }

Values

• Values within User Custom are generally objects such as Problem and Problem_UDF. They are stored as Strings or String Arrays in a hashmap (such as Problem Form Parameters) or as objects in the SesameSession Object
• Class and method variables can be any of these
• Generally, Strings and String arrays are used on the "user-facing" side, and Objects or ArrayLists of objects when dealing with the database
• It is generally easier to use the user facing ProblemFormParameters to manipulate data rather than the ArrayLists, so wherever possible, do the coding in these routines
• These are identifiable easily by the parameter lists
• In exits that are database oriented (primarily the ucAddPreInsert, ucEditPreUpdate ucAddPostInsert and ucEditPostUpdate routines) it is necessary to work with the Objects directly as well as the form parameters
• The session object can be used to store objects of arbitrary size, but this uses memory, and care should be taken to remove the object when it is no longer needed to prevent wasteful memory usage
• The memory will ultimately be returned when the session is invalidated, but depending on the session timeout, this can take some time.

Turning on Tracing of User Custom Calls

• To see all the calls to user custom methods and their timing information
  • As an ExtraView Administrator set USER_CUSTOM_ENABLE_METRICS = YES
  • View the log output using either tail –f evj.log (Unix / Linux) or an editor (Windows)
  • As you use ExtraView, the log will dynamically show the user custom methods called
• After Apache Tomcat (or your application server) is bounced, the log shows the current user custom class in use –
  

  2003-12-26 14:35:52 [  info   ]
  USER_CUSTOM_CLASSNAME=com.extraview.usercustom.myUserCustom3

• After Tomcat is bounced, the log shows the log’s name –
  

  2004-01-02 14:00:18 [  info   ]
  Manage Log Files Entered, prefix= art  , suffix= .log

• You can specify the name of the log file, which can make it easier to find the log you are using during development by modifying the ExtraView configuration file. The name of the log file is set in the file named Configuration.properties. This is stored in the directory named –
  
  %TOMCAT-HOME%\webapps\art\WEB-INF\configuration

  There will be a line like the following defining the log file’s name –

  LOG_FILE_PATH_NAME = logs/EVJ.log
• To make it easier to find you debug output in the log, with an editor select and delete the contents of the log before starting a debug run
• When tomcat is bounced, the log shows the database used by ExtraView and the user custom class that’s currently in use.

Determining your Code’s Performance

• To determine the performance impact of your user custom methods, turn on user custom metrics. Timing information will then be emitted to the ExtraView application server log
• To turn on tracing and metrics
  
  
  • Logon to ExtraView as an a user with administrator privileges
  • Select the Behavior Settings screen and set the value of the the behavior setting named USER_CUSTOM_ENABLE_METRICS to a value of YES
  • ExtraView will now make alog entry every time a user custom method is called and each entry has the number of milliseconds the call took to execute
  • If one of your user custom methods takes a second or longer to execute, it is probably degrading ExtraView’s performance significantly.

Determining Useful Methods of a Class

• An IDE (Integrated Development Environment) like Eclipse will show all the methods in a class. The debugger will show the value of objects, such passed user custom method parameters and ExtraView objects like Z
• To determine what is either useful or available from a user custom method parameter, look at its getXXX methods. For example, the SesameSession class has the following available methods
  
  
  • getUserId
  • getUserRole
  • getRemoteAddress
  • getArea
  • getProject
  • etc.
• Looking at the class’s Javadoc is another way to explore a class’s available methods. The getters and setters are typically the ones of most interest to the User Custom programmer

Log Your Messages

• The user custom method w(String) is an easy way to write debugging messages to the log
• By default, the messages will be at the level of WARN messages, making them easy to find
• The Z.log.writeToLog() method also writes to the log.