Monday, September 26, 2011

example using chkconfig

Redhat enterprise Linux comes with two nice commands

ntsysv - simple TUI (text based interface) interface for configuring runlevels.

chkconfig - chkconfig provides a simple command-line tool for maintaining the /etc/rc[0-6].d directory hierarchy by relieving system administrators of the task of directly manipulating the numerous symbolic links in those directories.

Turn on sshd service on boot

Code:
chkconfig sshd onTurn on MySQL service on boot

Code:
chkconfig mysqld onTurn on Apache / httpd service on boot

Code:
chkconfig httpd onTurn OFF Apache / httpd service on boot

Code:
chkconfig httpd offList if service is on of off on boot
Use --list option which lists all of the services which chkconfig knows about, and whether they are stopped or started in each runlevel:

Code:
/sbin/chkconfig --listSample O/p of above command

Code:
ipmi 0:off 1:off 2:off 3:off 4:off 5:off 6:off
rawdevices 0:off 1:off 2:off 3:on 4:on 5:on 6:off
NetworkManager 0:off 1:off 2:off 3:off 4:off 5:off 6:off
rpcidmapd 0:off 1:off 2:off 3:off 4:on 5:on 6:off
ntpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
readahead 0:off 1:off 2:off 3:off 4:off 5:on 6:off
cpuspeed 0:off 1:on 2:on 3:off 4:on 5:on 6:off
gpm 0:off 1:off 2:on 3:off 4:on 5:on 6:off
autofs 0:off 1:off 2:off 3:off 4:on 5:on 6:off
cups 0:off 1:off 2:on 3:off 4:on 5:on 6:off
lm_sensors 0:off 1:off 2:on 3:on 4:on 5:on 6:off
messagebus 0:off 1:off 2:off 3:on 4:on 5:on 6:off
network 0:off 1:off 2:on 3:on 4:on 5:on 6:off
xfs 0:off 1:off 2:on 3:off 4:on 5:on 6:off
saslauthd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
apf 0:off 1:off 2:on 3:on 4:on 5:on 6:off
nscd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
rhnsd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
snmptrapd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
xinetd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off
netplugd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
portmap 0:off 1:off 2:off 3:off 4:on 5:on 6:off
isdn 0:off 1:off 2:on 3:off 4:on 5:on 6:off
microcode_ctl 0:off 1:off 2:on 3:on 4:on 5:on 6:off
ypbind 0:off 1:off 2:off 3:off 4:off 5:off 6:off
kudzu 0:off 1:off 2:off 3:on 4:on 5:on 6:off
iptables 0:off 1:off 2:off 3:off 4:off 5:off 6:off
postfix 0:off 1:off 2:on 3:on 4:on 5:on 6:off
bluetooth 0:off 1:off 2:off 3:off 4:off 5:off 6:off
sysstat 0:off 1:on 2:on 3:on 4:on 5:on 6:off
diskdump 0:off 1:off 2:off 3:off 4:off 5:off 6:off
winbind 0:off 1:off 2:off 3:off 4:off 5:off 6:off
dovecot 0:off 1:off 2:on 3:on 4:on 5:on 6:off
named 0:off 1:off 2:off 3:off 4:off 5:off 6:off
nfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off
mysqld 0:off 1:off 2:off 3:on 4:off 5:off 6:off
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
auditd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
vsftpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
openibd 0:off 1:off 2:on 3:off 4:on 5:on 6:off
irda 0:off 1:off 2:off 3:off 4:off 5:off 6:off
monit 0:off 1:off 2:on 3:on 4:on 5:on 6:off
dc_client 0:off 1:off 2:off 3:off 4:off 5:off 6:off
readahead_early 0:off 1:off 2:off 3:off 4:off 5:on 6:off
netfs 0:off 1:off 2:off 3:on 4:on 5:on 6:off
squid 0:off 1:off 2:off 3:off 4:off 5:off 6:off
vmware 0:off 1:off 2:on 3:on 4:off 5:on 6:off
haldaemon 0:off 1:off 2:off 3:on 4:on 5:on 6:off
httpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
netdump 0:off 1:off 2:off 3:off 4:off 5:off 6:off
irqbalance 0:off 1:off 2:off 3:on 4:on 5:on 6:off
smartd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
snmpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
anacron 0:off 1:off 2:on 3:on 4:on 5:on 6:off
arptables_jf 0:off 1:off 2:on 3:on 4:on 5:on 6:off
nfslock 0:off 1:off 2:off 3:off 4:on 5:on 6:off
dc_server 0:off 1:off 2:off 3:off 4:off 5:off 6:off
crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off
psacct 0:off 1:off 2:on 3:on 4:on 5:on 6:off
mdmpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
tux 0:off 1:off 2:off 3:off 4:off 5:off 6:off
atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
acpid 0:off 1:off 2:off 3:on 4:on 5:on 6:off
spamassassin 0:off 1:off 2:on 3:on 4:on 5:on 6:off
pcmcia 0:off 1:off 2:on 3:off 4:on 5:on 6:off
rpcgssd 0:off 1:off 2:off 3:off 4:on 5:on 6:off
mdmonitor 0:off 1:off 2:on 3:on 4:on 5:on 6:off
xinetd based services:
cups-lpd: off
finger: off
eklogin: off
klogin: off
chargen: off
daytime-udp: off
krb5-telnet: off
time-udp: off
daytime: off
time: off
gssftp: off
kshell: off
echo-udp: off
rsync: off
tftp: off
vmware-authd: on
chargen-udp: off
echo: offType ntsysv for GUI tool

Code:
ntsysvType serviceconf - GUI tools need X GUI system

Code:
serviceconfShare
Share this post on Digg
Del.icio.us
Technorati
Twitter

Enabling and disabling services during start up in GNU/Linux

In any Linux distribution, some services are enabled to start at boot up by default. For example, on my machine, I have pcmcia, cron daemon, postfix mail transport agent ... just to name a few, which start during boot up. Usually, it is prudent to disable all services that are not needed as they are potential security risks and also they unnecessarily waste hardware resources. For example, my machine does not have any pcmcia cards so I can safely disable it. Same is the case with postfix which is also not used.



So how do you disable these services so that they are not started at boot time?



The answer to that depends on the type of Linux distribution you are using. True, many Linux distributions including Ubuntu bundle with them a GUI front end to accomplish the task which makes it easier to enable and disable the system services. But there is no standard GUI utility common across all Linux distributions. And this makes it worth while to learn how to enable and disable the services via the command line.



But one thing is common for all Linux distributions which is that all the start-up scripts are stored in the '/etc/init.d/' directory. So if you want to say, enable apache webserver in different run levels, then you should have a script related to the apache webserver in the /etc/init.d/ directory. It is usually created at the time of installing the software. And in my machine (which runs Ubuntu), it is named apache2. Where as in Red Hat, it is named httpd. Usually, the script will have the same name as the process or daemon.


Here I will explain different ways of enabling and disabling the system services.

1) Red Hat Method


Red Hat and Red Hat based Linux distributions make use of the script called chkconfig to enable and disable the system services running in Linux.



For example, to enable the apache webserver to start in certain run levels, you use the chkconfig script to enable it in the desired run levels as follows:

# chkconfig httpd --add# chkconfig httpd on --level 2,3,5This will enable the apache webserver to automatically start in the run levels 2, 3 and 5. You can check this by running the command:
# chkconfig --list httpdOne can also disable the service by using the off flag as shown below:
# chkconfig httpd off# chkconfig httpd --delRed Hat also has a useful script called service which can be used to start or stop any service. Taking the previous example, to start apache webserver, you execute the command:
# service httpd startand to stop the service...
# service httpd stopThe options being start, stop and restart which are self explanatory.

2) Debian Method


Debian Linux has its own script to enable and disable services across runlevels. It is called update-rc.d. Going by the above example, you can enable apache webserver as follows:

# update-rc.d apache2 defaults... this will enable the apache webserver to start in the default run levels of 2,3,4 and 5. Of course, you can do it explicitly by giving the run levels instead of the "defaults" keyword as follows:

# update-rc.d apache2 start 20 2 3 4 5 . stop 80 0 1 6 .The above command modifies the sym-links in the respective /etc/rcX.d directories to start or stop the service in the destined runlevels. Here X stands for a value of 0 to 6 depending on the runlevel. One thing to note here is the dot (.) which is used to terminate the set which is important. Also 20 and 80 are the sequence codes which decides in what order of precedence the scripts in the /etc/init.d/ directory should be started or stopped.


And to disable the service in all the run levels, you execute the command:
# update-rc.d -f apache2 removeHere -f option which stands for force is mandatory.


But if you want to enable the service only in runlevel 5, you do this instead:

# update-rc.d apache2 start 20 5 . stop 80 0 1 2 3 4 6 .3) Gentoo Method

Gentoo also uses a script to enable or disable services during boot-up. The name of the script is rc-update . Gentoo has three default runlevels. Them being: boot, default and nonetwork. Suppose I want to add the apache webserver to start in the default runlevel, then I run the command:

# rc-update add apache2 default... and to remove the webserver, it is as simple as :
# rc-update del apache2To see all the running applications at your runlevel and their status, similar to what is achieved by chkconfig --list, you use the rc-status command.
# rc-status --all4) The old fashioned way

I remember the first time I started using Linux, there were no such scripts to aid the user in enabling or disabling the services during start-up. You did it the old fashioned way which was creating or deleting symbolic links in the respective /etc/rcX.d/ directories. Here X in rcX.d is a number which stands for the runlevel. There can be two kinds of symbolic links in the /etc/rcX.d/ directories. One starts with the character 'S' followed by a number between 0 and 99 to denote the priority, followed by the name of the service you want to enable. The second kind of symlink has a name which starts with a 'K' followed by a number and then the name of the service you want to disable. So in any runlevel, at any given time, for each service, there should be only one symlink of the 'S' or 'K' variety but not both.



So taking the above example, suppose I want to enable apache webserver in the runlevel 5 but want to disable it in all other runlevels, I do the following:



First to enable the service for run level 5, I move into /etc/rc5.d/ directory and create a symlink to the apache service script residing in the /etc/init.d/ directory as follows:

# cd /etc/rc5.d/# ln -s /etc/init.d/apache2 S20apache2This creates a symbolic link in the /etc/rc5.d/ directory which the system interprets as - start (S) the apache service before all the services which have a priority number greater than 20.



If you do a long listing of the directory /etc/rc5.d in your system, you can find a lot of symlinks similar to the one below.

lrwxrwxrwx 1 root root 17 Mar 31 13:02 S20apache2 -> ../init.d/apache2Now if I start a service, I will want to stop the service while rebooting or while moving to single user mode and so on. So in those run levels I have to create the symlinks starting with character 'K'. So going back to the apache2 service example, if I want to automatically stop the service when the system goes into runlevel 0, 1 or 6, I will have to create the symlinks as follows in the /etc/rc0.d, /etc/rc1.d/, /etc/rc6.d/ directories.

# ln -s /etc/init.d/apache2 K80apache2One interesting aspect here is the priority. Lower the number, the higher is the priority. So since the starting priority of apache2 is 20 - that is apache starts way ahead of other services during startup, we give it a stopping priority of 80. There is no hard and fast rule for this but usually, you follow the formula as follows:



If you have 'N' as the priority number for starting a service, you use the number (100-N) for the stopping priority number and vice versa.



Basic premise:
/etc/inittab is a configuration file which describes which processes are started at bootup
The important config for startup programs launched is the run level: # The default runlevel is defined here
id:3:initdefault:.d/

Here Runlevel 3 is configured.
This means that services which Runlevel 3 is defined will be launched on startup.
All services that are enabled to run at startup for this level can be found in /etc/init.d/rc3.d Similarly, for other levels: rc0.d:
S20halt

rc1.d:
K02single K09splash K10fbset K21coldplug S01coldplug S12fbset S13kbd S13splash S20single

rc2.d:
K02gpm K07cups K10rpmconfigcheck K14splash_early K16syslog S01stqdaemon S07snmpd S09hprsm S13splash S17ivr
K04plweb K08hwscan K10running-kernel K15fazzt K17network S05network S07weblogic S12fbset S14hwscan S17splash_late
K05ivr K08xntpd K13cmanic K15informix K21coldplug S06syslog S08hpasm S12raw S14xntpd S18plweb
K05splash_late K09splash K13hprsm K15mms K21random S07fazzt S08resmgr S12rpmconfigcheck S15cups S20gpm
K06atd K10fbset K14hpasm K15snmpd S01coldplug S07informix S08splash_early S12running-kernel S16atd
K06cron K10raw K14resmgr K15weblogic S01random S07mms S09cmanic S13kbd S16cron

rc3.d:
K02gpm K06smb K09xinetd K12nfsboot K15informix S01random S08hpasm S12autofs S13splash S16cron
K04plweb K06squid K10autofs K13cmanic K15mms S01stqdaemon S08portmap S12fbset S13xinetd S16dhcpd
K05ivr K07cups K10fbset K13hprsm K15nmb S05network S08resmgr S12named S14hwscan S16hpsmhd
K05smbfs K07postfix K10named K13hpvca K15snmpd S06syslog S08splash_early S12orbacus S14nfsserver S16smb
K05splash_late K07rsyncd K10orbacus K13nfslock K15weblogic S07fazzt S09cmanic S12raw S14xntpd S16squid
K06atd K08hwscan K10raw K14hpasm K16syslog S07informix S09hprsm S12rpmconfigcheck S15cups S17ivr
K06autoyast K08nfsserver K10rpmconfigcheck K14portmap K17network S07mms S09hpvca S12running-kernel S15postfix S17smbfs
K06cron K08xntpd K10running-kernel K14resmgr K21coldplug S07nmb S09nfslock S12sshd S15rsyncd S17splash_late
K06dhcpd K09ct_intel K10sshd K14splash_early K21random S07snmpd S10nfs S13ct_intel S16atd S18plweb
K06hpsmhd K09splash K12nfs K15fazzt S01coldplug S07weblogic S10nfsboot S13kbd S16autoyast S20gpm

rc4.d:
K06hpsmhd K13cmanic K13hprsm K13hpvca K14hpasm S08hpasm S09cmanic S09hprsm S09hpvca S16hpsmhd

rc5.d:
K04plweb K06squid K09xinetd K12nfsboot K15informix S01random S08hpasm S12autofs S13splash S16autoyast
K05ivr K07cups K10autofs K13cmanic K15mms S01stqdaemon S08portmap S12fbset S13xinetd S16cron
K05smbfs K07postfix K10fbset K13hprsm K15nmb S05network S08resmgr S12named S14hwscan S16dhcpd
K05splash_late K07rsyncd K10named K13hpvca K15snmpd S06syslog S08splash_early S12orbacus S14nfsserver S16hpsmhd
K06atd K07xdm K10orbacus K13nfslock K15weblogic S07fazzt S09cmanic S12raw S14xntpd S16smb
K06autoyast K08hwscan K10raw K14hpasm K16syslog S07informix S09hprsm S12rpmconfigcheck S15cups S16squid
K06cron K08nfsserver K10rpmconfigcheck K14portmap K17network S07mms S09hpvca S12running-kernel S15postfix S17ivr
K06dhcpd K08xntpd K10running-kernel K14resmgr K21coldplug S07nmb S09nfslock S12sshd S15rsyncd S17smbfs
K06hpsmhd K09ct_intel K10sshd K14splash_early K21random S07snmpd S10nfs S13ct_intel S15xdm S17splash_late
K06smb K09splash K12nfs K15fazzt S01coldplug S07weblogic S10nfsboot S13kbd S16atd S18plweb

rc6.d:
S20reboot

rcS.d:
S10boot.clock S13kbd S13splash S20single

All files that start with the letter K are kill services (they call the service script with stop as an argument)
All files that start with the letter S are start services (they call the service script with start as an argument)
All Kill scripts are run first then all the Start scripts.
Both the Kill and Start scripts are run in numerical order (ie. S01... is run before S02...)
In the Runlevel 3 directory /etc/init.d/rc3.d you'll notice that all the services listed are symbolic links to a script in the /etc/init.d dir: lrwxrwxrwx 1 root root 11 2006-11-09 10:48 S07weblogic -> ../weblogic
lrwxrwxrwx 1 root root 8 2006-11-09 10:48 S07snmpd -> ../snmpd
lrwxrwxrwx 1 root root 6 2006-11-09 10:48 S07nmb -> ../nmb
lrwxrwxrwx 1 root root 6 2006-11-09 10:48 S07mms -> ../mms
lrwxrwxrwx 1 root root 11 2006-11-09 10:48 S07informix -> ../informix
lrwxrwxrwx 1 root root 8 2006-11-09 10:48 S07fazzt -> ../fazzt

Let's take a closer look at one of these services scheduled to launch on startup S07weblogic -> ../weblogic
The chkconfig command allows you to manage services for startup.
To check the configuration of a service script found in /etc/init.d run the following command: chkconfig --list weblogic
weblogic 0:off 1:off 2:on 3:on 4:off 5:on 6:off

This means the weblogic service is enabled for Runlevel 2,3, and 5 (ie. found in rc2.d, rc3.d and rc5.d directories
The weblogic script starts weblogic up at boot time when the system starts up under the above runlevels
The script looks like the following: #!/bin/sh
#
# weblogic start and shutdown
#
# Copyright (c) Shoppers Drug Mart 2005
#
# Bootup and shutdown script
#
# /etc/init.d/weblogic
#
### BEGIN INIT INFO
# Provides: weblogic
# Required-Start: $network $nfs $informix
# Required-Stop:
# Default-Start: 2 3 5
# Default-Stop:
# Description: Start weblogic server
### END INIT INFO

trap "exit 255" 1 2 3 # ignore signals

ADMIN_HOME=/apps/appserver/prod/asAdmin
case $1 in
'start')
echo "Starting weblogic..."
#
# have the system run out of /appserver/prod/asAdmin/
#
# start weblogic as asuser
#
su asuser -c "cd ${ADMIN_HOME}/utils; ./startServer.ksh ALL >${ADMIN_HOME}/logs/boot.log 2>&1" &
;;
'stop')
echo "Stopping weblogic..."
su asuser -c "cd ${ADMIN_HOME}/utils; ./stopServer.ksh ALL >${ADMIN_HOME}/logs/stop.log 2>&1"
;;
*)
echo "Usage: $0 {start|stop}"
;;
esac



anything you put in /etc/rc.d starting with rc. is run at startup. The file has to be executable also. Here is the content of script that was installed by default in my /etc/rc.d/rc.httpd


#!/bin/sh
#
# /etc/rc.d/rc.httpd
#
# Start/stop/restart the Apache web server.
#
# To make Apache start automatically at boot, make this
# file executable: chmod 755 /etc/rc.d/rc.httpd
#

case "$1" in
'start')
/usr/sbin/apachectl start ;;
'stop')
/usr/sbin/apachectl stop ;;
'restart')
/usr/sbin/apachectl restart ;;
*)
echo "usage $0 start|stop|restart" ;;
esac


As you can see, it is very alike but with a little more options. (restart is very useful).



NAME
chkconfig - updates and queries runlevel information for system services


SYNOPSIS
chkconfig --list [name]
chkconfig --add name
chkconfig --del name
chkconfig [--level levels] name
chkconfig [--level levels] name



DESCRIPTION
chkconfig provides a simple command-line tool for maintaining the /etc/rc[0-6].d directory hierarchy by relieving system administrators of the task of directly manipulating the numerous symbolic links in those directories.
This implementation of chkconfig was inspired by the chkconfig command present in the IRIX operating system. Rather than maintaining configuration information outside of the /etc/rc[0-6].d hierarchy, however, this version directly manages the symlinks in /etc/rc[0-6].d. This leaves all of the configuration information regarding what services init starts in a single location.

chkconfig has five distinct functions: adding new services for management, removing services from management, listing the current startup information for services, changing the startup information for services, and checking the startup state of a particular service.

When chkconfig is run without any options, it displays usage information. If only a service name is given, it checks to see if the service is configured to be started in the current runlevel. If it is, chkconfig returns true; otherwise it returns false. The --level option may be used to have chkconfig query an alternative runlevel rather than the current one.

If one of on, off, or reset is specified after the service name, chkconfig changes the startup information for the specified service. The on and off flags cause the service to be started or stopped, respectively, in the runlevels being changed. The reset flag resets the startup information for the service to whatever is specified in the init script in question.

By default, the on and off options affect only runlevels 2, 3, 4, and 5, while reset affects all of the runlevels. The --level option may be used to specify which runlevels are affected.

Note that for every service, each runlevel has either a start script or a stop script. When switching runlevels, init will not re-start an already-started service, and will not re-stop a service that is not running.



OPTIONS
--level levels
Specifies the run levels an operation should pertain to. It is given as a string of numbers from 0 to 7. For example, --level 35 specifies runlevels 3 and 5.

--add name
This option adds a new service for management by chkconfig. When a new service is added, chkconfig ensures that the service has either a start or a kill entry in every runlevel. If any runlevel is missing such an entry, chkconfig creates the appropriate entry as specified by the default values in the init script. Note that default entries in LSB-delimited 'INIT INFO' sections take precedence over the default runlevels in the initscript.


--del name
The service is removed from chkconfig management, and any symbolic links in /etc/rc[0-6].d which pertain to it are removed.

--list name
This option lists all of the services which chkconfig knows about, and whether they are stopped or started in each runlevel. If name is specified, information in only display about service name.


RUNLEVEL FILES
Each service which should be manageable by chkconfig needs two or more commented lines added to its init.d script. The first line tells chkconfig what runlevels the service should be started in by default, as well as the start and stop priority levels. If the service should not, by default, be started in any runlevels, a - should be used in place of the runlevels list. The second line contains a description for the service, and may be extended across multiple lines with backslash continuation.

For example, random.init has these three lines:

# chkconfig: 2345 20 80
# description: Saves and restores system entropy pool for \
# higher quality random number generation.
This says that the random script should be started in levels 2, 3, 4, and 5, that its start priority should be 20, and that its stop priority should be 80. You should be able to figure out what the description says; the \ causes the line to be continued. The extra space in front of the line is ignored.

Tuesday, September 13, 2011

What are XA transactions? What is a XA datasource?

An XA transaction, in the most general terms, is a "global transaction" that may span multiple resources. A non-XA transaction always involves just one resource. An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction. Non-XA transactions have no transaction coordinator, and a single resource is doing all its transaction work itself (this is sometimes called local transactions).

XA transactions come from the X/Open group specification on distributed, global transactions. JTA includes the X/Open XA spec, in modified form. Most stuff in the world is non-XA - a Servlet or EJB or plain old JDBC in a Java application talking to a single database. XA gets involved when you want to work with multiple resources - 2 or more databases, a database and a JMS connection, all of those plus maybe a JCA resource - all in a single transaction. In this scenario, you'll have an app server like Websphere or Weblogic or JBoss acting as the Transaction Manager, and your various resources (Oracle, Sybase, IBM MQ JMS, SAP, whatever) acting as transaction resources. Your code can then update/delete/publish/whatever across the many resources. When you say "commit", the results are commited across all of the resources. When you say "rollback", _everything_ is rolled back across all resources.

The Transaction Manager coordinates all of this through a protocol called Two Phase Commit (2PC). This protocol also has to be supported by the individual resources. In terms of datasources, an XA datasource is a data source that can participate in an XA global transaction. A non-XA datasource generally can't participate in a global transaction (sort of - some people implement what's called a "last participant" optimization that can let you do this for exactly one non-XA item).

Most developers have at least heard of XA, which describes the standard protocol that allows coordination, commitment, and recovery between transaction managers and resource managers.

Products such as CICS, Tuxedo, and even BEA WebLogic Server act as transaction managers, coordinating transactions across different resource managers. Typical XA resources are databases, messaging queuing products such as JMS or WebSphere MQ, mainframe applications, ERP packages, or anything else that can be coordinated with the transaction manager. XA is used to coordinate what is commonly called a two-phase commit (2PC) transaction. The classic example of a 2PC transaction is when two different databases need to be updated atomically. Most people think of something like a bank that has one database for savings accounts and a different one for checking accounts. If a customer wants to transfer money between his checking and savings accounts, both databases have to participate in the transaction or the bank risks losing track of some money.

The problem is that most developers think, "Well, my application uses only one database, so I don't need to use XA on that database." This may not be true. The question that should be asked is, "Does the application require shared access to multiple resources that need to ensure the integrity of the transaction being performed?" For instance, does the application use Java 2 Connector Architecture adapters, the BEA WebLogic Server Messaging Bridge, or the Java Message Service (JMS)? If the application needs to update the database and any of these other resources in the same transaction, then both the database and the other resource need to be treated as XA resources.

In addition to Web or EJB applications that may touch different resources, XA is often needed when building Web services or BEA WebLogic Integration applications. Integration applications often span disparate resources and involve asynchronous interfaces. As a result, they frequently require 2PC. An extremely common use case for WebLogic Integration that calls for XA is to pull a message from WebSphere MQ, do some business processing with the message, make updates to a database, and then place another message back on MQ. Usually this whole process has to occur in a guaranteed and transactional manner. There is a tendency to shy away from XA because of the performance penalty it imposes. Still, if transaction coordination across multiple resources is needed, there is no way to avoid XA. If the requirements for an application include phrases such as "persistent messaging with guaranteed once and only once message delivery," then XA is probably needed.

Figure 1 shows a common, though extremely simplified, BEA WebLogic Integration process definition that needs to use XA. A JMS message is received to start the process. Assume the message is a customer order. The order then has to be placed in the order shipment database and placed on another message queue for further processing by a legacy billing application. Unless XA is used to coordinate the transaction between the database and JMS, we risk updating the shipment database without updating the billing application. This could result in the order being shipped, but the customer might never be billed.

Once you've determined that your application does in fact need to use XA, how do we make sure it is used correctly? Fortunately, J2EE and the Java Transaction API (JTA) hide the implementation details of XA. Coding changes are not required to enable XA for your application. Using XA properly is a matter of configuring the resources that need to be enrolled in the same transaction. Depending on the application, the BEA WebLogic Server resources that most often need to be configured for XA are connection pools, data sources, JMS Servers, JMS connection factories, and messaging bridges. Fortunately, the entire configuration needed on the WebLogic side can be done from the WebLogic Server Console.

Before worrying about the WebLogic configuration for XA, we have to ensure that the resources we want to access are XA enabled. Check with the database administrator, the WebSphere MQ administrator, or whoever is in charge of the resources that are outside WebLogic. These resources do not always enable XA by default, nor do all resources support the X/Open XA interface, which is required to truly do XA transactions. For example, some databases require that additional scripts be run in order to enable XA.

For those resources that do not support XA at all, some transaction managers allow for a "one-phase" optimization. In a one-phase optimization, the transaction manager issues a "prepare to commit" command to all of the XA resources. If all of the XA resources respond affirmatively, the transaction manager will commit the non-XA resource. The transaction manager will then commit all of the XA resources. This allows the transaction manager to work with a non-XA resource, but normally only one XA resource per transaction is allowed. There is a small chance that something will go wrong after committing the non-XA resource and before the XA resources all commit, but this is the best alternative if a resource just doesn't support XA.

Connection pools are where most people start configuring WebLogic for XA. The connection pool needs to use an XA driver. Most database vendors provide XA drivers for their databases. BEA WebLogic Server 8.1 SP2 ships with a number of XA drivers for Oracle, DB2, Informix, SQL Server, and Sybase. We need to ensure that the Driver classname on the connection pool page of the BEA WebLogic Console is in fact an XA driver. When using the configuration wizards in BEA WebLogic Server 8.1, the wizards always note which drivers are XA enabled.

When more than one XA driver is available for the database involved, be sure to run some benchmarks to determine which driver gives the best performance. Sometimes different drivers for the same database implement XA in completely different ways. This leads to wide variances in performance. For example, the Oracle 9.2 OCI Driver implements XA natively, while the Oracle 9.2 Thin Driver relies on stored procedures in the database to implement XA. As a result, the Oracle 9.2 OCI driver generally performs XA transactions much faster than the Thin driver. Oracle's newest Type 4 driver, the 10g Thin Driver, also implements XA natively and is backwards compatible with some previous versions of the Oracle database. Taking the time to fully evaluate alternative drivers can lead to significant performance improvements.