Enable trace for wsadmin script

You can enable trace for tracking transaction and debugging problems when you execute the wsadmin script. You can do that by setting these two properties in the wsadmin.properties file


#-------------------------------------------------------------------------
# The traceFile property determines where trace and logging
# output are directed. If more than one user will be using
# wsadmin simultaneously, different traceFile properties should
# be set in user properties files.
# The default is that all tracing and logging go to the console;
# it is recommended that a value be specified here.
# If the file name contains DBCS characters, use unicode format such as \uxxxx, where xxxx is a number
#-------------------------------------------------------------------------
com.ibm.ws.scripting.traceFile=C:/Cert/WebSphere/AppServer/profiles/Dmgr01/logs/wsadmin.traceout

#-------------------------------------------------------------------------
# The traceString property governs the trace in effect for
# the scripting client process.
# The default is no tracing.
#-------------------------------------------------------------------------
com.ibm.ws.scripting.traceString=com.ibm.*=all=enabled


By default com.ibm.ws.scripting.traceString property is commented so first uncomment it. You can also change the location of the trace file which is logs folder by default.

I tried enabling the trace and then installing enterprise application using wsadmin script, it generates lots of log statements like these


[8/18/09 11:05:59:535 PDT] 0000000a AbstractShell > normalizeFQPathName - C:/Cert/WebSphere/AppServer/bin/securityProcs.jacl;C:/Cert/WebSphere/AppServer/bin/LTPA_LDAPSecurityProcs.jacl Entry
[8/18/09 11:05:59:535 PDT] 0000000a AbstractShell 3 path after converting separator: C:\Cert\WebSphere\AppServer\bin\securityProcs.jacl;C:\Cert\WebSphere\AppServer\bin\LTPA_LDAPSecurityProcs.jacl
[8/18/09 11:05:59:535 PDT] 0000000a AbstractShell < normalizeFQPathName - C:\Cert\WebSphere\AppServer\bin\securityProcs.jacl;C:\Cert\WebSphere\AppServer\bin\LTPA_LDAPSecurityProcs.jacl Exit
[8/18/09 11:05:59:535 PDT] 0000000a WasxShell 3 processing profile: C:\Cert\WebSphere\AppServer\bin\securityProcs.jacl
[8/18/09 11:05:59:535 PDT] 0000000a WasxShell 3 converted profile name: C:\Cert\WebSphere\AppServer\bin\securityProcs.py
[8/18/09 11:05:59:535 PDT] 0000000a WasxShell 3 using language: jython
[8/18/09 11:05:59:550 PDT] 0000000a AbstractShell > getSanitizedScriptString Entry
[8/18/09 11:05:59:550 PDT] 0000000a AbstractShell < getSanitizedScriptString Exit
[8/18/09 11:05:59:566 PDT] 0000000a WasxShell 3 processing profile: C:\Cert\WebSphere\AppServer\bin\LTPA_LDAPSecurityProcs.jacl
[8/18/09 11:05:59:566 PDT] 0000000a WasxShell 3 converted profile name: C:\Cert\WebSphere\AppServer\bin\LTPA_LDAPSecurityProcs.py
[8/18/09 11:05:59:566 PDT] 0000000a WasxShell 3 using language: jython
[8/18/09 11:05:59:597 PDT] 0000000a AbstractShell > getSanitizedScriptString Entry
[8/18/09 11:05:59:597 PDT] 0000000a AbstractShell < getSanitizedScriptString Exit
[8/18/09 11:05:59:644 PDT] 0000000a WasxShell < executeProfiles Exit
[8/18/09 11:05:59:644 PDT] 0000000a AbstractShell > executeCommands Entry
[8/18/09 11:05:59:644 PDT] 0000000a AbstractShell 3 executeScript c:/temp/appinstall.py
[8/18/09 11:05:59:644 PDT] 0000000a AbstractShell > executeScript Entry
[8/18/09 11:05:59:644 PDT] 0000000a AbstractShell 3 using language: jython
[8/18/09 11:05:59:660 PDT] 0000000a AbstractShell A WASX7091I: Executing script: "c:/temp/appinstall.py"
[8/18/09 11:05:59:660 PDT] 0000000a AbstractShell > getSanitizedScriptString Entry
[8/18/09 11:05:59:660 PDT] 0000000a AbstractShell < getSanitizedScriptString Exit
[8/18/09 11:05:59:660 PDT] 0000000a AdminAppClien > install: Entry
c:/temp/ConnectionLeakEAR.ear
[ -nopreCompileJSPs -distributeApp -nouseMetaDataFromBinary -nodeployejb -appname ConnectionLeakEAR -createMBeansForResources -noreloadEnabled -nodeployws -validateinstall warn -noprocessEmbeddedConfig -filepermission .*\.dll=755#.*\.so=755#.*\.a=755#.*\.sl=755 -noallowDispatchRemoteInclude -noallowServiceRemoteInclude]
[8/18/09 11:05:59:660 PDT] 0000000a AbstractShell > setLastException Entry
[8/18/09 11:05:59:660 PDT] 0000000a AbstractShell 3 in script mode; not saving exception
[8/18/09 11:05:59:660 PDT] 0000000a AdminAppClien > doInstall Entry
c:/temp/ConnectionLeakEAR.ear
[ -nopreCompileJSPs -distributeApp -nouseMetaDataFromBinary -nodeployejb -appname ConnectionLeakEAR -createMBeansForResources -noreloadEnabled -nodeployws -validateinstall warn -noprocessEmbeddedConfig -filepermission .*\.dll=755#.*\.so=755#.*\.a=755#.*\.sl=755 -noallowDispatchRemoteInclude -noallowServiceRemoteInclude]
false
[8/18/09 11:05:59:660 PDT] 0000000a LanguageUtili > optionsToHashtable -- [ -nopreCompileJSPs -distributeApp -nouseMetaDataFromBinary -nodeployejb -appname ConnectionLeakEAR -createMBeansForResources -noreloadEnabled -nodeployws -validateinstall warn -noprocessEmbeddedConfig -filepermission .*\.dll=755#.*\.so=755#.*\.a=755#.*\.sl=755 -noallowDispatchRemoteInclude -noallowServiceRemoteInclude] Entry
[8/18/09 11:05:59:660 PDT] 0000000a JythonUtiliti > cleanAttributeString Entry
[8/18/09 11:05:59:660 PDT] 0000000a JythonUtiliti < cleanAttributeString -- -nopreCompileJSPs -distributeApp -nouseMetaDataFromBinary -nodeployejb -appname ConnectionLeakEAR -createMBeansForResources -noreloadEnabled -nodeployws -validateinstall warn -noprocessEmbeddedConfig -filepermission .*\.dll=755#.*\.so=755#.*\.a=755#.*\.sl=755 -noallowDispatchRemoteInclude -noallowServiceRemoteInclude Exit
[8/18/09 11:05:59:660 PDT] 0000000a JythonUtiliti > getTokenizerString Entry
[8/18/09 11:05:59:660 PDT] 0000000a JythonUtiliti < getTokenizerString Exit
[8/18/09 11:05:59:660 PDT] 0000000a LanguageUtili 3 Top: next: " "
[8/18/09 11:05:59:660 PDT] 0000000a JythonUtiliti > addOptionValue: nopreCompileJSPs Entry
[8/18/09 11:05:59:660 PDT] 0000000a JythonUtiliti 3 next: -distributeApp
[8/18/09 11:05:59:660 PDT] 0000000a JythonUtiliti < addOptionValue: Exit
[8/18/09 11:05:59:660 PDT] 0000000a LanguageUtili 3 added option value...
[8/18/09 11:05:59:660 PDT] 0000000a JythonUtiliti > addOptionValue: distributeApp Entry
[8/18/09 11:05:59:660 PDT] 0000000a JythonUtiliti 3 next: -nouseMetaDataFromBinary


Administrative properties for wsadmin script

Scripting administration utilizes several Java property files. Property files can be used to control your system configurations. Before any property file is specified on the command line, three levels of default property files are loaded. These property files include an installation default file, a user default file, and a properties file.

The first level represents an installation default, located in the /profile_root/properties directory for each application server profile called wsadmin.properties. The second level represents a user default, and is located in the Java user.home property. This properties file is also called wsadmin.properties. The third level is a properties file that is pointed to by the WSADMIN_PROPERTIES environment variable. This environment variable is defined in the environment where the wsadmin tool starts.

If one or more of these property files is present, they are interpreted before any properties file that is present on the command line. The three levels of property files load in the order that they are specified. The properties file that is loaded last overrides the ones loaded earlier.

This is the sample wsadmin.properties file from my machine, it has detailed description of what each of the properties mean.

#-------------------------------------------------------------------------
# Properties file for scripting client
# Cell Manager version
#-------------------------------------------------------------------------
#
#-------------------------------------------------------------------------
# The connectionType determines what connector is used.
# It can be SOAP or RMI.
# The default is SOAP.
#-------------------------------------------------------------------------
com.ibm.ws.scripting.connectionType=SOAP
#com.ibm.ws.scripting.connectionType=RMI

#-------------------------------------------------------------------------
# The port property determines what port is used when attempting
# a connection.
# The default SOAP port for a dmgr or custom profile is 8879
#-------------------------------------------------------------------------
com.ibm.ws.scripting.port=8879

#-------------------------------------------------------------------------
# The host property determines what host is used when attempting
# a connection.
# The default value is localhost.
#-------------------------------------------------------------------------
com.ibm.ws.scripting.host=localhost

#-------------------------------------------------------------------------
# The defaultLang property determines what scripting language to use.
# Supported values are jacl and jython.
# The default value is jacl.
#-------------------------------------------------------------------------
com.ibm.ws.scripting.defaultLang=jython

#-------------------------------------------------------------------------
# The echoparams property determines whether parameters or arguments are
# outputed to STDOUT or to wsadmin trace file. User can disable the property
# for security purpose to not output parameters to STDOUT or to wsadmin trace.
# The default value is true.
#-------------------------------------------------------------------------
com.ibm.ws.scripting.echoparams=true

#-------------------------------------------------------------------------
# The traceFile property determines where trace and logging
# output are directed. If more than one user will be using
# wsadmin simultaneously, different traceFile properties should
# be set in user properties files.
# The default is that all tracing and logging go to the console;
# it is recommended that a value be specified here.
# If the file name contains DBCS characters, use unicode format such as \uxxxx, where xxxx is a number
#-------------------------------------------------------------------------
com.ibm.ws.scripting.traceFile=C:/Cert/WebSphere/AppServer/profiles/Dmgr01/logs/wsadmin.traceout

#-------------------------------------------------------------------------
# The validationOutput property determines where validation
# reports are directed. If more than one user will be using
# wsadmin simultaneously, different validationOutput properties should
# be set in user properties files.
# The default is wsadmin.valout in the profile directory.
# If the file name contains DBCS characters, use unicode format such as \uxxxx, where xxxx is a number
#-------------------------------------------------------------------------
com.ibm.ws.scripting.validationOutput=C:/Cert/WebSphere/AppServer/profiles/Dmgr01/logs/wsadmin.valout

#-------------------------------------------------------------------------
# The traceString property governs the trace in effect for
# the scripting client process.
# The default is no tracing.
#-------------------------------------------------------------------------
com.ibm.ws.scripting.traceString=com.ibm.*=all=enabled

#-------------------------------------------------------------------------
# The profiles property is a list of profiles to be run before
# running user commands, scripts, or an interactive shell.
# securityProcs is included here by default to make security
# configuration easier.
#-------------------------------------------------------------------------
com.ibm.ws.scripting.profiles=C:/Cert/WebSphere/AppServer/bin/securityProcs.jacl;C:/Cert/WebSphere/AppServer/bin/LTPA_LDAPSecurityProcs.jacl

#-------------------------------------------------------------------------
# The emitWarningForCustomSecurityPolicy property controls whether
# message WASX7207W is emitted when custom permissions are found.
# Possible values are: true, false
# The default is "true"
#-------------------------------------------------------------------------
# com.ibm.ws.scripting.emitWarningForCustomSecurityPolicy=true

#-------------------------------------------------------------------------
# The tempdir property determines what directory to use for temporary
# files when installing applications.
# The default is that the JVM decides -- this is java.io.tmpdir
#-------------------------------------------------------------------------
com.ibm.ws.scripting.tempdir=c:/temp/applicationinstall

#-------------------------------------------------------------------------
# The validationLevel property determines what level of validation to
# use when configuration changes are made from the scripting interface.
# Possible values are: NONE, LOW, MEDIUM, HIGH, HIGHEST
# The default is HIGHEST
#-------------------------------------------------------------------------
com.ibm.ws.scripting.validationLevel=HIGHEST

#-------------------------------------------------------------------------
# The crossDocumentValidationEnabled property determines whether the validation
# mechanism examines other documents when changes are made to one document.
# Possible values are: true, false
# The default is true
#-------------------------------------------------------------------------
#com.ibm.ws.scripting.crossDocumentValidationEnabled=

#-------------------------------------------------------------------------
# The classpath property is appended to the list of paths to search for
# classes and resources.
# There is no default value.
#-------------------------------------------------------------------------
#com.ibm.ws.scripting.classpath=


jacl2jython utility

Both Jacl and Jython scripting languages are supported in WebSphere Application Server but JACL is deprecated and you should develop all your new wsadmin scripts using Jython. If you have existing JACL scripts then you can use the jacl2jython utility shipped with WebSPhere Application Server toolkit to convert your jacl script into jython script. This utility is meant to do most of the preliminary conversions and once the syntax conversion is done, you will have to manually verify the script to resolve problems and make sure that it is converted as per your intention. Take a look at Migrating administrative script to Jython section for further information

I tried using this this conversion utility to convert Hello World jacl script to jython by following these steps

• Create test.jacl script like this
  
puts "Hello world"

  


• Then go to <applicationservertoolkitroot>/bin folder and execute Jacl2Jython.bat c:\temp\test.jacl to convert my test.jacl into jython file


• The conversion utility creates a .py file in the same directory as that of the .jacl script, in my case it created test.py file like this
  

  
  import sys
  def wsadminToList(inStr):
          outList=[]
          if (len(inStr)>0 and inStr[0]=='[' and inStr[-1]==']'):
                  tmpList = inStr[1:-1].split(" ")
          else:
                  tmpList = inStr.split("\n")  #splits for Windows or Linux
          for item in tmpList:
                  item = item.rstrip();        #removes any Windows "\r"
                  if (len(item)>0):
                          outList.append(item)
          return outList
  #endDef
  
  print "Hello world"
  

  
  

If you search for wsadmin script samples on google most of the examples that you will find are developed using the JACL syntax so this utility comes in handy to convert those samples into jython

WebSphere Application Server data source properties

You can set the properties that apply to the WebSphere Application Server connection, rather than to the database connection, by selecting the WebSphere Application Server data source properties link under the Additional Properties section of the data source configuration page.

• Statement Cache Size: Specify the number of prepared statements that are cached per connection. A prepared statement is a precompiled SQL statement that is stored in a prepared statement object. This object is used to execute the given SQL statement multiple times. The WebSphere Application Server data source optimizes the processing of prepared statements. In general, the more statements your application has, the larger the cache should be. For example, if the application has five SQL statements, set the statement cache size to 5, so that each connection has five statements.


• Enable multithreaded access detection :If you enable this feature, the application server detects the existence of access by multiple threads.


• Enable database reauthentication: Connection pool searches do not include the user name and password. If you enable this feature, a connection can still be retrieved from the pool, but you must extend the DataStoreHelper class to provide implementation of the doConnectionSetupPerTransaction() method where the reauthentication takes place. Connection reauthentication can help improve performance by reducing the overhead of opening and closing connections, particularly for applications that always request connections with different user names and passwords.


•  Manage cached handles: When you call the getConnection() method to access a database, you get a connection handle returned. The handle is not the physical connection, but a representation of a physical connection. The physical connection is managed by the connection manager. A cached handle is a connection handle that is held across transaction and method boundaries by an application. This setting specifies whether cached handles should be tracked by the container. This can cause overhead and only should be used in specific situations. For more information about cached handles, see the Connection Handles topic in the Information Center.


• Transaction context logging: The J2EE programming model indicates that connections should always have a transaction context. However, some applications do not have a context associated with them. This option tells the container to log that there is a missing transaction context in the activity log when the connection is
  obtained.


• Pretest existing pooled connections: If you check this box, the application server tries to connect to this data source before it attempts to send data to or receive data from this source. If you select this property, you can specify how often, in seconds, the application server retries to make a connection if the initial attempt fails. The pretest SQL string is sent to the database to test the connection.


• Pretest new connections: If you check this box, the application server test the initial connection to database. If you select this property, you specify how often, in seconds, the application server retries to make a connection and how many times it tries. The pretest SQL string is sent to the database to test the connection.

Data Source Connection pool properties

You can configure connection pool related properties from the Connection pool screen.

• Connection Timeout: Specify the interval, in seconds, after which a connection request times out and a ConnectionWaitTimeoutException is thrown. This can occur when the pool is at its maximum (Max Connections) and all of the connections are in use by other applications for the duration of the wait. For example, if Connection Timeout is set to 300 and the maximum number of connections is reached, the Pool Manager waits for 300 seconds for an available physical connection. If a physical connection is not available within this time, the Pool Manager throws a ConnectionWaitTimeoutException.


• Max Connections: Specify the maximum number of physical connections that can be created in this pool. These are the physical connections to the back-end database. Once this number is reached, no new physical connections are created and the requester waits until a physical connection that is currently in use is returned to the pool, or a ConnectionWaitTimeoutException is thrown. For example, if Max Connections is set to 5, and there are five physical connections in use, the Pool Manager waits for the amount of time specified in Connection Timeout for a physical connection to become free. If, after that time, there are still no free connections, the Pool Manager throws a ConnectionWaitTimeoutException to the application.


• Min Connections: Specify the minimum number of physical connections to be maintained. Until this number is reached, the pool maintenance thread does not discard any physical connections. However, no attempt is made to bring the number of
  connections up to this number. For example, if Min Connections is set to 3, and one physical connection is created, that connection is not discarded by the Unused Timeout thread. By the same token, the thread does not automatically create two additional physical connections to reach the Min Connections setting.


• Reap Time: Specify the interval, in seconds, between runs of the pool maintenance
  thread. For example, if Reap Time is set to 60, the pool maintenance thread runs every 60 seconds. The Reap Time interval affects the accuracy of the Unused Timeout and Aged Timeout settings. The smaller the interval you set, the greater the accuracy. When the pool maintenance thread runs, it discards any connections that have been unused for longer than the time value specified in Unused Timeout, until it reaches the number of connections specified in Min Connections. The pool maintenance thread also discards any connections that remain active longer than the time value specified in Aged Timeout.


• Unused Timeout: Specify the interval in seconds after which an unused or idle connection is discarded. For example, if the unused timeout value is set to 120, and the pool maintenance thread is enabled (Reap Time is not 0), any physical connection that remains unused for two minutes is discarded. Note that accuracy of this timeout, as well as performance, is affected by the Reap Time value. See the Reap Time bullet for more information.


• Aged Timeout: Specify the interval in seconds before a physical connection is discarded, regardless of recent usage activity. Setting Aged Timeout to 0 allows active physical connections to remain in the pool indefinitely. For example, if the Aged Timeout value is set to 1200, and the Reap Time value is not 0, any physical connection that remains in existence for 1200 seconds (20 minutes) is discarded from the pool. Note that accuracy of this timeout, as well as performance, is affected by the Reap Time value. See Reap Time for more information.


• Purge Policy: Specify how to purge connections when a stale connection or fatal connection error is detected. Valid values are EntirePool and FailingConnectionOnly. If you choose EntirePool, all physical connections in the pool are destroyed when a stale connection is detected. If you choose FailingConnectionOnly, the pool attempts to destroy only the stale connection. The other connections remain in the pool. Final destruction of connections that are in use at the time of the error might be delayed. However, those connections are never returned to the pool.

Data Source Custom Properties

You can set the database vendor specific custom properties on data source by clicking on custom properties link on data source definition page.



This is what i see on the custom properties page for Apache Derby data source. I can enable the data source level SQL trace from here, Ex. i can turn on the trace to see what all SQL queries are getting fired on the SQL connection from this data source,
the input parameters and the result set.

As you can see there is some help available for each of the custom property that you can set


I did set traceLevel to 4, that enables only TRACE_RESULTSET_CALLS, and i set value of traceFile to c:/temp/derbytrace.log file. After setting these properties i tried accessing the data source and this is the log that got generated in the derbytrace.log

Similarly you can set custom properties specific to your data source to generate trace

[derby][Time:1250572072484][Thread:WebContainer : 0][ClientConnectionPoolDataSource@5000500] getPooledConnection () called
[derby][Time:1250572072593][Thread:WebContainer : 0][ClientConnectionPoolDataSource@5000500] getPooledConnection () returned org.apache.derby.client.ClientPooledConnection@78987898
[derby][Time:1250572072593][Thread:WebContainer : 0][ClientPooledConnection@78987898] getConnection () called
[derby][Time:1250572072593][Thread:WebContainer : 0][ClientPooledConnection@78987898] getConnection () returned org.apache.derby.client.am.LogicalConnection@77807780
[derby][Time:1250572072609][Thread:WebContainer : 0][org.apache.derby.client.net.NetConnection@20242024] getMetaData () returned DatabaseMetaData@6fe66fe6
[derby][Time:1250572072734][Thread:WebContainer : 0][org.apache.derby.client.net.NetConnection@20242024] getHoldability () returned 1
[derby][Time:1250572072734][Thread:WebContainer : 0][org.apache.derby.client.net.NetConnection@20242024] getAutoCommit () returned true
[derby][Time:1250572072734][Thread:WebContainer : 0][org.apache.derby.client.net.NetConnection@20242024] getCatalog () returned null
[derby][Time:1250572072734][Thread:WebContainer : 0][org.apache.derby.client.net.NetConnection@20242024] isReadOnly () returned false
[derby][Time:1250572072734][Thread:WebContainer : 0][org.apache.derby.client.net.NetConnection@20242024] setTransactionIsolation (4) called
[derby][Time:1250572072734][Thread:WebContainer : 0][org.apache.derby.client.am.Statement@2cc62cc6] executeUpdate (SET CURRENT ISOLATION = RS) called
[derby][Time:1250572072750][Thread:WebContainer : 0][org.apache.derby.client.am.Statement@2cc62cc6] executeUpdate () returned 0
[derby][Time:1250572072781][Thread:WebContainer : 0][org.apache.derby.client.net.NetConnection@20242024] clearWarnings () called
[derby][Time:1250572072781][Thread:WebContainer : 0][org.apache.derby.client.net.NetConnection@20242024] createStatement (1003, 1007) called
[derby][Time:1250572072781][Thread:WebContainer : 0][org.apache.derby.client.net.NetConnection@20242024] createStatement () returned Statement@1b401b4
[derby][Time:1250572072796][Thread:WebContainer : 0][org.apache.derby.client.am.Statement@1b401b4] executeQuery (SELECT * FROM DERBY.EMPLOYEE) called
[derby][Time:1250572072828][Thread:WebContainer : 0][org.apache.derby.client.am.Statement@1b401b4] executeQuery () returned ResultSet@1bae1bae
[derby][Time:1250572072843][Thread:WebContainer : 0][ResultSet@1bae1bae] next () called
[derby][Time:1250572072843][Thread:WebContainer : 0][ResultSet@1bae1bae] next () returned true
[derby][Time:1250572072843][Thread:WebContainer : 0][ResultSet@1bae1bae] getObject (1) called
[derby][Time:1250572072843][Thread:WebContainer : 0][ResultSet@1bae1bae] getObject () returned 1
[derby][Time:1250572072843][Thread:WebContainer : 0][ResultSet@1bae1bae] getObject (2) called
[derby][Time:1250572072843][Thread:WebContainer : 0][ResultSet@1bae1bae] getObject () returned Sunil Patil
[derby][Time:1250572072843][Thread:WebContainer : 0][ResultSet@1bae1bae] next () called
[derby][Time:1250572072843][Thread:WebContainer : 0][ResultSet@1bae1bae] next () returned true
[derby][Time:1250572072843][Thread:WebContainer : 0][ResultSet@1bae1bae] getObject (1) called
[derby][Time:1250572072843][Thread:WebContainer : 0][ResultSet@1bae1bae] getObject () returned 2
[derby][Time:1250572072843][Thread:WebContainer : 0][ResultSet@1bae1bae] getObject (2) called
[derby][Time:1250572072843][Thread:WebContainer : 0][ResultSet@1bae1bae] getObject () returned Alden Taylor
[derby][Time:1250572072843][Thread:WebContainer : 0][ResultSet@1bae1bae] next () called
[derby][Time:1250572072843][Thread:WebContainer : 0][ResultSet@1bae1bae] next () returned false
[derby][Time:1250572072843][Thread:WebContainer : 0][ResultSet@1bae1bae] close () called
[derby][Time:1250572072843][Thread:WebContainer : 0][org.apache.derby.client.am.Statement@1b401b4] close () called


What is HAManager

WebSphere V6 introduces a new concept for advanced failover and thus higher availability, called the High Availability Manager (HAManager). The HAManager enhances the availability of WebSphere singleton services like transaction services or JMS message services. It runs as a service within each application server process that monitors the health of WebSphere clusters. In the event of a server failure, the HAManager will failover the singleton service and recover any in-flight transactions.

What is failover

The proposition to have multiple servers (potentially on multiple independent machines) naturally leads to the potential for the system to provide failover. That is, if any one machine or server in the system were to fail for any reason, the system should continue to operate with the remaining servers. The load balancing property should ensure that the client load gets redistributed to the remaining servers, each of which will take on a proportionately slightly higher percentage of the total load. Of course, such an arrangement assumes that the system is designed with some degree of overcapacity, so that the remaining servers are indeed sufficient to process the total expected client load.

Ideally, the failover aspect should be totally transparent to clients of the system. When a server fails, any client that is currently interacting with that server should be automatically redirected to one of the remaining servers, without any interruption of service and without requiring any special action on the part of that client. In practice, however, most failover solutions may not be completely transparent. For example, a client that is currently in the middle of an operation when a server fails may receive an error from that operation, and may be required to retry (at which point the client would be connected to another, still available server). Or the client may observe a pause or delay in processing, before the processing of its requests resumes automatically with a different server. The important point in failover is that each client, and the set of clients as a whole, is able to eventually continue to take advantage of the system and receive service, even if some of the servers fail and become unavailable.

Conversely, when a previously failed server is repaired and again becomes available, the system may transparently start using that server again to process a portion of the total client load.

What is availability or resiliency

Availability is the description of the system’s ability to respond to requests no matter the circumstances. Availability requires that the topology provide some degree of process redundancy in order to eliminate single points of failure. While vertical scalability can provide this by creating multiple processes, the physical machine then becomes a single point of failure. For this reason, a high availability topology typically involves horizontal scaling across multiple machines.

Using a WebSphere Application Server multiple machine configuration eliminates a given application server process as a single point of failure. In WebSphere Application Server V5.0 and higher, the removal of the application dependencies on the administrative server process for security, naming and transactions further reduces the potential that a single process failure can disrupt processing on a given node. In fact, the only single point of failure in a WebSphere cell is the Deployment Manager, where all central administration is performed. However, a failure at the Deployment Manager only impacts the ability to change the cell configuration and to run the Tivoli Performance Viewer which is now included in the Administrative Console; application servers are more self-sufficient in WebSphere Application Server V5.0 and higher compared to WebSphere Application Server V4.x.

What is work load management WLM

Workload management is a WebSphere Facility to provide load balancing and affinity
between application servers in a WebSphere clustered environment. Websphere uses
workload management to send requests to alternate members of the cluster. WebSphere also routes the concurrent requests from a user to the application server that serviced the first request, as EJB calls and session state will be memory of this application server.

The proposed configuration should ensure that each machine or server in the configuration processes a fair share of the overall client load that is being processed by the system as a whole. In other words, it is not efficient to have one machine overloaded while another machine is mostly idle. If all machines have roughly the same capacity (for example, CPU power), each should process a roughly equal share of the load. Otherwise, there likely needs to be a provision for workload to be distributed in proportion to the processing power available on each machine.

Furthermore, if the total load changes over time, the system should automatically adapt itself; for example, all machines may use 50% of their capacity, or all machines may use 100% of their capacity. But not one machine uses 100% of its capacity while the rest uses 15% of their capacity.