- AdminControl:The AdminControl scripting object is used for operational control. It communicates with MBeans that represent live objects running a WebSphere server process. It includes commands to query existing running objects and their attributes and invoke operations on the objects.
- AdminConfig: The AdminConfig object is used to manage the configuration information that is stored in the repository. This object communicates with the WebSphere Application Server configuration service component to make configuration inquires and changes. In a distributed server environment, the AdminConfig commands are available only if a scripting client is connected to the deployment manager. When connected to a node agent or a managed application server, the AdminConfig commands will not be available because the configuration for these server processes are copies of the master configuration that resides in the deployment manager.
- AdminApp: The AdminApp object can update application metadata, map virtual hosts to Web modules, and map servers to modules for applications already installed. Changes to an application, such as specifying a library for the application to use or setting session management configuration properties, are performed using the AdminConfig object.
- AdminTask: The AdminTask object is used to access a set of task-oriented administrative commands that provide an alternative way to access the configuration commands and the running object management commands. The administrative commands run simple and complex commands. The administrative commands are discovered dynamically when the scripting client is started. The set of available administrative commands depends on the edition of WebSphere Application Server you install. You can use the AdminTask object commands to access these commands.
WSAdmin Objects
The wsadmin command exposes following four objects
WSAdmin command invocation
The wsadmin command can be invoked in three different ways
Rational application developer has a Jython development perspective that lets you develop and execute Jython commands from within IDE and it also lets you debug your script
In this screen shot i am executing createWASVariable.py script from IDE on my DMGR. I need to specify soap port of DMGR and Admin user login information here
- Invoking Single command: You can invoke single command of wsadmin by executing
wsadmin -c AdminControl.getNode() - Invoking commands interactively: If you want to execute more than one command then you can execute wsadmin in interactive mode, This is the default mode of wsadmin and you can invoke it by not passing either -c or -f options. Once you do that the wsadmin prompt will appear and you can execute wsadmin scripting commands on the prompt.
- Running script file (-f): If you have set of predefined scripts then you can execute
wsadmin -f <filename>command to execute the script file.
Rational application developer has a Jython development perspective that lets you develop and execute Jython commands from within IDE and it also lets you debug your script
In this screen shot i am executing createWASVariable.py script from IDE on my DMGR. I need to specify soap port of DMGR and Admin user login information here
WSAdmin security hardening
When you execute the wsadmin script you will have to pass the username and password for the user as command line parameter. But one of my client had this hardening requirement that we should not pass user name and password on command line because if someone is running ps at the same time they could see the command line parameters. Since i was writing automation script i could not prompt user for user name password. So i did set following things
- Change \profiles\AppSrv01\properties\soap.client.properties file,
set value of com.ibm.SOAP.loginUserid property to the userId of the admin user and value of com.ibm.SOAP.loginPassword property to the password of the admin user and then set value of com.ibm.SOAP.loginSource property to blank.
com.ibm.SOAP.loginUserid=wasadmin
com.ibm.SOAP.loginPassword=wasadmin
#------------------------------------------------------------------------------
# SOAP Login Prompt
#
# The auto prompting will happen only if all of the following are met:
#
# - Running from a SOAP client
# - Server is reachable and server security is enabled
# - Username and password are not provided either on command line or in this
# file
# - com.ibm.SOAP.loginSource below is set to either "stdin" or "prompt"
#
# stdin: prompt in command window
# prompt: GUI dialog box; falls back to stdin if GUI not allowed
#
# (So to disable auto prompting, set loginSource to nothing)
#------------------------------------------------------------------------------
com.ibm.SOAP.loginSource= - Now the password is set in plain text which is a security problem so you can use the PropFilePasswordEncoder utility to encode the admin user password in the soap.client.properties file.
View administrative script command for last action
WebSPhere Application Server 6.1 has this cool feature, that when you perform some adminstrative action using the WAS Admin console, it will let you get the Wsadmin script command to for the action that you performed using WAS COnsole
I tried installing ConnectionLeak.Ear file and i used the default options for every thing, on the last screen of Install application wizard i saw "View administrative scripting command for last action" link on the right hand side. Clicking on that link generates the equivalent wsadmin command like this
I can save the command as a script file and then execute it from the command line. This feature is very helpful when your trying to automate administration, first you can perform the administrative command using WAS Admin console and then copy script, and parameterize it.
I tried installing ConnectionLeak.Ear file and i used the default options for every thing, on the last screen of Install application wizard i saw "View administrative scripting command for last action" link on the right hand side. Clicking on that link generates the equivalent wsadmin command like this
I can save the command as a script file and then execute it from the command line. This feature is very helpful when your trying to automate administration, first you can perform the administrative command using WAS Admin console and then copy script, and parameterize it.
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
By default
I tried enabling the trace and then installing enterprise application using wsadmin script, it generates lots of log statements like these
#-------------------------------------------------------------------------
# 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.
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
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
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.jaclto 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
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
Subscribe to:
Posts (Atom)