User: d_jencks
Date: 01/08/24 12:09:33
Modified: src/docs jbossdocs.xml resource.xml
Log:
updated build.xml and config.xml to work a little better in buildmagic and included
draft of chapter on resources
Revision Changes Path
1.24 +18 -6 manual/src/docs/jbossdocs.xml
Index: jbossdocs.xml
===================================================================
RCS file: /cvsroot/jboss/manual/src/docs/jbossdocs.xml,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- jbossdocs.xml 2001/08/17 14:31:49 1.23
+++ jbossdocs.xml 2001/08/24 19:09:33 1.24
@@ -20,10 +20,10 @@
<!ENTITY howtojbuilderdebug.xml SYSTEM "howtojbuilderdebug.xml">
<!ENTITY howtoejx.xml SYSTEM "howtoejx.xml">
<!ENTITY howtojca.xml SYSTEM "howtojca.xml">
- <!ENTITY howtojndi_external.xml SYSTEM "howtojndi_external.xml">
+ <!ENTITY howtojndiexternal.xml SYSTEM "howtojndi_external.xml">
<!ENTITY basicconfiguration.xml SYSTEM "basicconfiguration.xml">
<!ENTITY jbossjms.xml SYSTEM "jbossjms.xml">
- <!ENTITY howto_socketfactories.xml SYSTEM "howto_socketfactories.xml">
+ <!ENTITY howtosocketfactories.xml SYSTEM "howto_socketfactories.xml">
<!ENTITY howtojaxp.xml SYSTEM "howtojaxp.xml">
<!ENTITY howtojpda.xml SYSTEM "howtojpda.xml">
<!ENTITY howtojetty.xml SYSTEM "howtojetty.xml">
@@ -32,10 +32,11 @@
<!ENTITY jbosssx.xml SYSTEM "jbosssx.xml">
<!ENTITY howtonetbeansdebug.xml SYSTEM "howtonetbeansdebug.xml">
<!ENTITY howtovisualagedebug.xml SYSTEM "howtovisualagedebug.xml">
- <!ENTITY howto_webcontainer.xml SYSTEM "howto_webcontainer.xml">
+ <!ENTITY howtowebcontainer.xml SYSTEM "howto_webcontainer.xml">
<!ENTITY webconfig.xml SYSTEM "webconfig.xml">
<!ENTITY howtoejbdoclet.xml SYSTEM "howtoejbdoclet.xml">
<!ENTITY howtoclientapplet.xml SYSTEM "howtoclientapplet.xml">
+ <!ENTITY resource.xml SYSTEM "resource.xml">
]>
<book>
<bookinfo>
@@ -49,6 +50,17 @@
&preface.xml;
&jbossintro.xml;
&basicconfiguration.xml;
+<chapter id="resource">
+ <title>Using Databases and other Enterprise Resources</title>
+ <para>
+ <author>
+ <firstname>David</firstname>
+ <surname>Jencks</surname>
+ </author>
+ <email>[EMAIL PROTECTED]</email>
+ </para>
+&resource.xml;
+</chapter>
<chapter id="jdbc">
<title>JDBC</title>
<para>
@@ -84,12 +96,12 @@
&howtonetbeansdebug.xml;
&howtoejx.xml;
&howtojca.xml;
-&howtojndi_external.xml;
-&howto_socketfactories.xml;
+&howtojndiexternal.xml;
+&howtosocketfactories.xml;
&howtojaxp.xml;
&howtoverifier.xml;
&howtopetstore.xml;
-&howto_webcontainer.xml;
+&howtowebcontainer.xml;
&howtoejbdoclet.xml;
&howtoclientapplet.xml;
</chapter>
1.3 +229 -17 manual/src/docs/resource.xml
Index: resource.xml
===================================================================
RCS file: /cvsroot/jboss/manual/src/docs/resource.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- resource.xml 2001/08/16 02:53:17 1.2
+++ resource.xml 2001/08/24 19:09:33 1.3
@@ -1,44 +1,256 @@
<?xml version="1.0" encoding="UTF-8"?>
-<section>
+<!--DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"docbookx/docbookx.dtd"-->
+<section id="resource-intro">
<title>Introduction</title>
- <section>
+ <section id="resource-intro-access">
<title>Access to Resource Managers</title>
- <para>In order for your ejbs to do much useful work, they will need to
communicate with a transactional resource manager such as a relational database,
transactional message que, or other enterprise information system. Jboss now supports
all such communication through the jca specification using Resource Adaptes. This
technology provides a uniform way to combine the application server's transaction
management and connection pooling functionalities with a resource adapters ability to
connect to and do work with a resource manager.</para>
+ <para>This chapter is primarily relevant to jboss 3.0 (rabbithole)</para>
+ <para>In order for your ejbs to do much useful work, they will need to
communicate with a transactional resource manager such as a relational database,
transactional message queue, or other enterprise information system. Jboss now
supports all such communication using Resource Adapters following the jca 1.0
specification (NEED LINK). This technology provides a uniform way to combine the
application server's transaction management and connection pooling functionalities
with a resource adapter's ability to connect to and do work with a resource
manager.</para>
<para>Jboss provides the ability to deploy any compliant resource adapter, and
connections from any adapter may be pooled by jboss, obtained from connection
factories bound in jndi, and used by client code. At the moment, however, only
connection factories implementing javax.sql.DataSource and connections implementing
java.sql.Connection may be used with CMP beans and JAWS to automate database
access.</para>
<para>Since few database vendors have supplied resource adapters for their
database products, the usual strategy for accessing relational databases consists of
using a generic resource adapter that wraps a jdbc driver into a jca resource adapter.
Jboss comes with two such adapters, one for jdbc 1 drivers without xa transaction
support, and one for jdbc 2 drivers implementing xa support with XADataSource and
XAConnection.</para>
- <para>As well as providing a systematic, well thought out framework for pooling
and transaction control for relational databases, jca also provides another
specification ("cci") for connection factories and connections unrelated to jdbc. An
adaptor could use these to provide predefined access to stored procedures in a
relational database, or these could be used to access a message que, or enterprise
information system such as CICS or SAP. Although there are no particular conceptual
difficulties in using such resource adapters with CMP beans, support for this is not
yet integrated into jboss. </para>
+ <para>As well as providing a systematic, well thought out framework for pooling
and transaction control that can be used for relational databases, jca also provides
another specification ("cci") for connection factories and connections unrelated to
jdbc. An adaptor could use these to provide predefined access to stored procedures in
a relational database, or these could be used to access a message que, or enterprise
information system such as CICS or SAP. Although there are no particular conceptual
difficulties in using such resource adapters to automatically manage persistence of
CMP beans, support for this is not yet integrated into jboss. </para>
</section>
- <section>
+ <section id="resource-intro-pooling">
<title>Why pooling?</title>
- <para></para>
+ <para>Most often connections to resource managers such as relational databases
take a significant amount of time to set up and consume a significant amount of
resources. It would be unacceptably inefficient to construct, use, and tear down a
physical connection for each client request in an application server environment, nor
would it usually be appropriate to reserve a connection for each user. Some means of
sharing and reusing expensive connections is necessary. The jca solution to this
involves ManagedConnections, which are "physical" connections to the resource manager
provided by the resource adapter, and which are pooled by the ConnectionManager
provided by the application server, and short lived connection handles to these
ManagedConnections, which can be handed out on demand and returned (closed) when done
with. Note that there are three layers here: a client (or persistence framework such
as JAWS) requests a (resource adapter-specific) connection from a
(resource-adapter-specific) connection factory; the connection factory basically
typecasts a generic connection handle from the (jboss supplied) ConnectionManager,
which has just obtained the connection handle from a ManagedConnection (from the
resource adapter) that it retrieved (from a pool) or created.</para>
</section>
- <section>
+ <section id="resource-intro-transactionsupport">
<title>Levels of Transaction Support</title>
- <para></para>
+ <para>There are three levels of transaction support mentioned in the jca
specification: full xa support for distributed transactions with two phase commit,
single phase local (to a single resource manager/adapter) transactions, and no
transaction support. Since the ConnectionManager mediates all connection handles
supplied to clients, it is also the component that mediates between the transaction
manager and the connections, making sure that each managed connection is enrolled in
the correct transaction for the client that currently has its connection handle. For
example, database XADataSource-based drivers can be wrapped into resource adapters
supporting xa transactions, whereas database jdbc 1.0 drivers can be wrapped into
resource adapters supporting local transactions.</para>
</section>
- <section>
+ <section id="resource-intro-overview">
<title>Organization</title>
<para>We will start with an overview of the components of a resource adapter
and related parts of an application server, and how these are set up in jboss. We
proceed with a description of how to configure a connection factory for an arbitrary
resource adapter, followed by instructions for using the specific jdbc wrapper
resource adapters provided with jboss for non xa and xa jdbc drivers. This will be
followed by a detailed discussion with examples of how to set up these wrappers for
the most commonly used databases. If you are using a database not listed here, please
contribute a working setup to help others. Finally we discuss migration from the
previous jboss implementation, the XADataSourceLoader.</para>
</section>
- <section>
+ <section id="resource-architecture">
<title>Resource Adapter Architecture and JBoss</title>
- <para></para>
+ <para>Here we present a list of many of the classes you need for a resource
adapter setup, with descriptions of their purpose and whether they are part of the
resource adapter or jboss.</para>
+ <orderedlist>
+ <listitem>
+ <formalpara>
+ <title>ConnectionFactory (resource adapter)</title>
+ <para>This is what your client program (or JAWS) uses to get the
connections to do its work. The most familiar example is the javax.sql.DataSource,
supplying db connections. The resource cci spec describes another sort of connection
that provides a way to get at less standardized resource managers. The connections
from the connection factory do not represent actual resource manager connections but
rather short-lived handles to them to be used only briefly during actual resource
access. "Closing" such a handle merely indicates you are done using it, not that the
underlying connection to the resource should be disposed of. When a connection is
requested, the ConnectionFactory simply asks the ConnectionManager for one.</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>ConnectionManager (jboss)</title>
+ <para>The connection manager provides pooling functionality and makes
sure connections are hooked up to the right transactions. It doesn't know anything
about what kind of connections its dealing with, just how to pool them and hook up
transactions. Now what it's actually pooling are ManagedConnections, which we'll get
to in a minute. When it needs another one, it asks the ManagedConnectionFactory.
When you ask for a connection, it finds or creates a managed connection and gets a
connection handle from the managed connection to return to you. When it is looking
for a ManagedConnection, it gets to use two criteria: ConnectionRequestInfo and
Subject. The ConnectionRequestInfo comes from the ConnectionFactory, and contains
resource adapter specific per-connection configuration information, such as client id
or language. The connection manager does not know the internal structure of
ConnectionRequestInfo, but passes it unchanged to the ManagedConnectionFactory. The
subject comes from a PrincipalMapping, which may supply a "constant" user or may
translate the principal information from the client context into a resource-adapter
suitable subject. The ConnectionRequestInfo and Subject are parameters for creating a
new ManagedConnection; if preexisting pooled connections are available, the
ConnectionManager asks the ManagedConnectionFactory for a match based on the
ConnectionRequestInfo and Subject from among the available ManagedConnections. </para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>ManagedConnectionFactory (Resource adapter)</title>
+ <para>The ManagedConnectionFactory actually creates and configures the
actual connections to the resource manager we're doing all this work to get to. This
is really the only part of the resource adapter you can configure at deployment time,
telling it usually what resource instance (such as database) and possibly user and
password to connect to. When the ConnectionManager needs another physical connection
to use, it asks the ManagedConnectionFactory.</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>ManagedConnection</title>
+ <para>The ManagedConnection is the actual physical connection to the
resource. In its interface it doesn't really do anything itself, but provides two
kinds of handles so you can do something with it: Connections so you can do work in
the resource, and transaction management handles consisting of either XAResource for
controlling xa (two phase) transactions or LocalTransaction for resources that do not
support the xa protocol.</para>
+ </formalpara>
+ </listitem>
+ </orderedlist>
+ <para>In addition, there are several classes provided by jboss to get all this
set up. You will mostly be dealing with ConnectionFactoryLoader mbean configuration.
After a resource adapter is deployed, which makes the classes available and checks
that all the necessary parts are identified, the ConnectionFactoryLoader will
instantiate and configure instances of many of the classes listed above to prepare for
access to a specific resource instance. In particular it uses a
ConnectionManagerFactory to create a ConnectionManager instance for this connector
instance.</para>
</section>
<section>
<title>Configuring a connection factory for an arbitrary resource
adapter.</title>
- <para> </para>
+ <para>There are three major pieces of the connector framework that can be
configured: the ManagedConnectionFactory, where you configure such resource adapter
specific properties as which resource instance you are connecting to and transaction
isolation, the ConnectionManager where you specify pooling policies, and the
PrincipalMapping -- how to determine who the resource user is and how to authenticate
that user. Each of these is configured using text in the Properties.load file format.
In addition, you need to specify many classes and mbeans to get just the
configuration you want.</para>
+ <formalpara>
+ <title>Attributes of a ConnectionFactoryLoader mbean configuration</title>
+ <para><orderedlist>
+ <listitem>
+ <formalpara>
+ <title>mbean code="org.jboss.resource.ConnectionFactoryLoader"
+ name="DefaultDomain:service=ConnectionFactoryLoader,name=DefaultDS"</title>
+ <para>This is the mbean declaration, identifying it as a
ConnectionFactoryLoader instance and supplying an ObjectName. Note that the
name="myObjectName" is part of the ConnectionFactoryLoader mbean ObjectName and has
nothing to do with the jndi name the ConnectionFactory will be bound under.</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>JndiName (formerly FactoryName)</title>
+ <para>This is the JNDI name that the ConnectionFactory will end up
getting bound under in JNDI. You or JAWS use this to find the ConnectionFactory when
you want to do some work on the resource it is connected to.</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>TransactionManagerName</title>
+ <para>This is the jndi name of the transaction manager to hook up
transactions from. Normally it is java:/TransactionManager</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>RARDeployerName</title>
+ <para>This is the (string representation of) the mbean ObjectName of
the connector deployer. This is needed because usually the ConnectionFactoryLoader is
configured and started before the resource adapter is deployed. When the resource
adapter is deployed, all the ConnectionFactoryLoaders are notified that they can
finish their setup and actually create the ManagedConnectionFactory etc.</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>ResourceAdapterName</title>
+ <para>This is a little more interesting! Finally we specify which
resource adapter this ConnectionFactory should be using. This is the display-name
element from the resource adapter's internal deployment descriptor (ra.xml)</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>ManagedConnectionFactoryProperties</title>
+ <para>These are, in Properties.load file format, all the
configuration you want to do on the ManagedConnectionFactory. Typically this will
include what resource you are connecting to and such adapter specific items as
transaction isolation. The configurable items are specified in the resource adapter's
deployment descriptor (ra.xml)</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>ConnectionManagerFactoryName</title>
+ <para>This is the jndi name of a ConnectionManagerFactory. By
specifying the ConnectionManagerFactory, you are specifying what kind of connection
manager you want to use. There are three choices supplied with JBoss providing
different levels of transaction support: none, local, and xa. They all rely on the
same pooling code, although they will behave differently when receiving multiple
requests for a connection from within the same transaction. If you wish to provide
alternate pooling or other ConnectionManager functionality, you must provide both a
ConnectionManager and a ConnectionManagerFactory, and provide a
ConnectionManagerFactoryLoader configuration section in jboss.jcml to make the factory
available.</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>ConnectionManagerProperties</title>
+ <para>For the three jboss ConnectionManagers, this configures, in
property file format, the pooling parameters.
+ <orderedlist>
+ <listitem>
+ <formalpara>
+ <title>MinSize</title>
+ <para>The initial and minimum number of managed connections
in the pool</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>MaxSize</title>
+ <para>The maximum number of managed connections in the pool.
Requests beyond this will block or return null depending on the value of the Blocking
parameter. ????is returning null supported by the spec????</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>Blocking</title>
+ <para>(true, false). If true, requests for connections when
there are none available will block. If false, such requests will return null. ???Is
this speccompliant???</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>IdleTimeoutEnabled</title>
+ <para>(true, false). If true, ManagedConnections idle for
the idle timeout value will be disposed of. If false, ManagedConnections will remain
in the pool indefinitely. Note that if your resource manager closes connections after
a period of inactivity you should set this true and adjust the idle timeout value to
match your resource managers characteristics. Note that the scan for idle connections
occurs with the same frequence as the garbage collection, controlled by the
GCIntervalMillis parameter, so you will want to adjust this value as well. The
default value for GCInterval is 2 minutes.CHECKTHIS</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>IdleTimeoutMillis</title>
+ <para>This is the (minimum) time for the connection manager
to wait in milliseconds before closing unused connections. This is used only if
IdleTimeoutEnabled is true.</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>MaxIdleTimeoutPercent</title>
+ <para>(0.0 .. 1.0)Despite the name "Percent" suggesting a
value between 0 and 100, this parameter must be between 0.0 and 1.0. It controls the
amount a pool can shrink due to idle timouts closing connections. If 0.0, each time
idle connections are closed, if n are closed, n-1 will be created anew so the pool
size is reduced by one. If 1.0, connections are created only if necessary to get back
to the pool minimum size. </para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>GCEnabled</title>
+ <para>(true, false) Garbage collection reclaims connections
that havebeen held too long (as determined by the GCIntervalMillis parameter) by a
client. If a reclaimed connection is still valid, as determined by
ManagedConnection.cleanup() returning without an exception, the connection is made
immediately available in the pool. If the connection cannot be reclaimed, as
determined by the cleanup() method throwing a ResourceException, the connection is
discarded.</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>GCMinIdleMillis</title>
+ <para>The time a connection can be held by a client before
being reclaimed by the pool without the client releasing it, if GCEnabled is
true.</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>GCIntervalMillis</title>
+ <para>The time between garbage collection/ idle timeout
removal runs. This may not be exact due to server load.</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>TimestampUsed</title>
+ <para>(true, false) If true, PoolEvents will update the
timestamp, preventing garbage collection/idle timeout. It is not clear to me at the
moment if PoolEvents can be generated for this purpose except on getting or closing
connections and starting or ending resources and committing or rolling back
transactions.</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>InvalidateOnError</title>
+ <para>(true, false) Sets whether a connection is removed from
the pool in case of error. The errors come from a PoolEvent announcing an error. I
don't know how such PoolEvents are generated.</para>
+ </formalpara>
+ </listitem>
+ </orderedlist>
+ </para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>PrincipalMappingClass</title>
+ <para>In order to get a connection, you need a
javax.security.auth.Subject. This class is responsible for mapping the
callerPrincipal used in the rest of the application to a Subject of the appropriate
form for use with the resource manager. For instance for a database, this subject
normally contains a user name and password. The ManyToOnePrincipalMapping ignores the
callerPrincipal and always returns a Subject with PrivateCredentials consisting of a
PasswordCredential containing the userName and password specified in the
PrincipalMappingProperties. Non database resource adapters may require other
principal mappings or Subject credentials.</para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>PrincipalMappingProperties</title>
+ <para>This provides, in Properties.load file format, the properties
for the PrincipalMappingClass instance. For the ManyToOnePrincipalMapping, these
properties consist of userName and password.</para>
+ </formalpara>
+ </listitem>
+ </orderedlist>
+</para>
+ </formalpara>
</section>
- <section>
+ <section id="resource-jdbc-wrappers">
<title>Configuring the jdbc wrapper resource adapters</title>
- <para></para>
+ <para>As for any resource adapter, all the resource adapter specific
configuration must be done with the ManagedConnectionFactoryProperties entry. Let's
consider the contents separately for the two wrappers. </para>
+ <section id="resource-jdbc-wrappers-local">
+ <title>LocalTransaction wrapper for jdbc 1 (non-xa) drivers</title>
+ <para>Here are the available properties to configure.
+ <itemizedlist>
+ <listitem>
+ <para>UserName (String). The username used to create JDBC connections.
This can also be supplied via the PrincipalMapping class, for instance the
ManyToOnePrincipalMapping can provide a "constant" user/password.</para>
+ </listitem>
+ <listitem>
+ <para>Password (String). The default password used to create a JDBC
connection. As for UserName, this can be supplied by the PrincipalMapping.</para>
+ </listitem>
+ <listitem>
+ <para>ConnectionURL (String). The jdbc URL used to create jdbc
connections from java.sql.Driver.</para>
+ </listitem>
+ <listitem>
+ <para>Driver (String). The class name of the JDBC driver that handles
this jdbc URL. Note that it is preferred to use this property rather than the
JDBCProvider previously required.</para>
+ </listitem>
+ <listitem>
+ <para>TransactionIsolation (String). The string name of the desired
transaction isolation for the connections. The allowed strings are the names of the
static Connection members, TRANSACTION_SERIALIZABLE, TRANSACTION_REPEATABLE_READ,
TRANSACTION_READ_COMMITTED, TRANSACTION_READ_UNCOMMITTED, TRANSACTION_NONE. Note that
not all values are supported by all databases. Alternatively, you may use (the string
representation of) the integer value for the transaction isolation level. This may be
useful if a driver supports a nonstandard isolation level.</para>
+ </listitem>
+ <listitem>
+ <para>AutoCommit (String). You are strongly advised not to set this.
The autocommit property is set false by default for connections obtained from this
adapter wrapper. This property is included only to provide emulation of the obsolete
JDBCDataSourceLoader which provided no transaction support and left autocommit
true.</para>
+ </listitem>
+ </itemizedlist>
+</para>
+ </section>
+ <section id="resource-jdbc-wrappers-xa">
+ <title>XA Transaction wrapper for jdbc 2 XADataSource drivers</title>
+ <para>Here are the available properties to configure.
+ <itemizedlist>
+ <listitem>
+ <para>XADataSourceClass (String). The class name of the underlying
XADataSource driver. This specifies what driver is being wrapped.</para>
+ </listitem>
+ <listitem>
+ <para>XADataSourceProperties (String) These are the properties needed
to configure the underlying XADataSource. They must be in the format of name=value
pairs separated by semicolons, with no spaces. For example,
name1=value1;name2=value2;name3=value3. The most typical use for this is the url for
the database instance you are connecting to.</para>
+ </listitem>
+ <listitem>
+ <para>UserName (String). The username used to create JDBC connections.
This can also be supplied via the PrincipalMapping class, for instance the
ManyToOnePrincipalMapping can provide a "constant" user/password.</para>
+ </listitem>
+ <listitem>
+ <para>Password (String). The default password used to create a JDBC
connection. As for UserName, this can be supplied by the PrincipalMapping.</para>
+ </listitem>
+ <listitem>
+ <para>TransactionIsolation (String). The string name of the desired
transaction isolation for the connections. The allowed strings are the names of the
static Connection members, TRANSACTION_SERIALIZABLE, TRANSACTION_REPEATABLE_READ,
TRANSACTION_READ_COMMITTED, TRANSACTION_READ_UNCOMMITTED, TRANSACTION_NONE. Note that
not all values are supported by all databases. Alternatively, you may use (the string
representation of) the integer value for the transaction isolation level. This may be
useful if a driver supports a nonstandard isolation level.</para>
+ </listitem>
+ </itemizedlist>
+</para>
+ </section>
</section>
- <section>
+ <section id="resource-db-specific">
<title>Examples for specific databases</title>
<para></para>
</section>
- <section>
+ <section id="resource-migration">
<title>Migration from older jboss versions</title>
- <para>Previous versions of jboss provided database connectivity and connection
pooling through the XADataSourceLoaderMBean. This was normally used with the
XADataSourceImpl, which provided an xa interface for a non-xa jdbc driver. Of course,
since the underlying driver did not support xa transactions, neither did the "XA"
wrapper. These drivers can now be used with the Minerva JDBC LocalTransaction
ResourceAdapter, which works with the transaction manager using local, non-xa
transactions, eliminating the confusion of imitating but not implementing xa
semantics. If you have a true XADataSource implementation for your database, you can
instead use the Minerva JDBC XATransaction ResourceAdapter, which provides full xa
support.</para>
+ <para>Previous versions of jboss provided database connectivity and connection
pooling through the XADataSourceLoaderMBean. This was normally used with the
XADataSourceImpl, which provided an xa interface for a non-xa jdbc driver. Of course,
since the underlying driver did not support xa transactions, neither did the XA
wrapper. These drivers can now be used with the Minerva JDBC LocalTransaction
ResourceAdapter, which works with the transaction manager using local, non-xa
transactions, eliminating the confusion of imitating but not implementing xa
semantics. If you have a true XADataSource implementation for your database, you can
instead use the Minerva JDBC XATransaction ResourceAdapter, which provides full xa
support.</para>
<para>In this version of jboss, the XADataSourceLoader has been rewritten to
assist you in migrating to this new architecture. This mbean now accepts the
configuration information from jboss.jcml, and creates a ConnectionFactoryLoader mbean
with the appropriate connection pool and Minerva Resource Adapter and equivalent
configuration. You can complete the conversion by saving your mbean configuration to
a file using the ConfigurationService mbean, copying the new ConnectionFactoryLoader
mbean configuration into your jboss.jcml file, and removing the
XADataSourceLoader.</para>
<para>The migration results in the following conversions:
<orderedlist>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
