Hopefully this link will explain things in detail: http://bit.ly/bsl9Un The relevant bits include the following...
Emulated data sources are data sources
that emulate the XA protocol for JTA
transactions. Emulated data sources
offer OC4J caching, pooling, and
Oracle JDBC extensions for Oracle data
sources. Historically, emulated data
sources were necessary because many
JDBC drivers did not provide XA
capabilities. Today even though most
JDBC drivers do provide XA
capabilities, there are still cases in
which emulated XA is preferred (such
as transactions that do not require
two-phase commit.)
Connections obtained from emulated
data sources are extremely fast,
because the connections emulate the XA
API without providing full XA global
transactional support. In particular,
emulated data sources do not support
two-phase commit. Oracle recommends
that you use emulated data sources for
local transactions, or when your
application uses global transactions
without requiring two-phase commit.
And...
Nonemulated data sources provide full
(nonemulated) JTA services, including
two-phase commit capabilities for
global transactions. Nonemulated data
sources offer pooling, caching,
distributed transactions capabilities,
and vendor JDBC extensions (currently,
only Oracle JDBC extensions). For
information on the limitations of
two-phase commit, see Chapter 7, "Java
Transaction API".
Oracle recommends that you use
nonemulated data sources for
distributed database communications,
recovery, and reliability. Nonemulated
data sources share physical
connections for logical connections to
the same database for the same user.
So what is happening when you set emulated XA is that your app thinks it is getting XA but the calls are optimized or translated to single-phase commit. When you specify non-emulated XA then you are getting the full XA functionality. Either way, the app is blissfully unaware.