Author: buildbot
Date: Thu Apr 28 11:14:54 2016
New Revision: 986928
Log:
Staging update by buildbot for aries
Modified:
websites/staging/aries/trunk/content/ (props changed)
websites/staging/aries/trunk/content/modules/transactioncontrol.html
Propchange: websites/staging/aries/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Thu Apr 28 11:14:54 2016
@@ -1 +1 @@
-1741201
+1741413
Modified: websites/staging/aries/trunk/content/modules/transactioncontrol.html
==============================================================================
--- websites/staging/aries/trunk/content/modules/transactioncontrol.html
(original)
+++ websites/staging/aries/trunk/content/modules/transactioncontrol.html Thu
Apr 28 11:14:54 2016
@@ -278,25 +278,64 @@ h2:hover > .headerlink, h3:hover > .head
}
h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink,
h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink,
dt:hover > .elementid-permalink { visibility: visible }</style>
<h2 id="osgi-transaction-control-service">OSGi Transaction Control Service<a
class="headerlink" href="#osgi-transaction-control-service" title="Permanent
link">¶</a></h2>
-<p>This set of modules is an implementation of the proposed OSGi Transaction
Control Service and related services, such as JDBC and JPA resource
providers.</p>
-<p>The Transaction Control Service (RFC-221) is an in-progress RFC publicly
available from the OSGi Alliance:
https://github.com/osgi/design/blob/master/rfcs/rfc0221/rfc-0221-TransactionControl.pdf</p>
-<p>Given that the RFC is non-final the OSGi API declared in this project is
subject to change at any time up to its official release. Also the behaviour of
this implementation may not always be up-to-date with the latest wording in the
RFC. The project maintainers will, however try to keep pace with the RFC, and
to ensure that the implementations are compliant with any OSGi specifications
that result from the RFC.</p>
+<p>This set of modules is an implementation of the proposed OSGi Transaction
Control Service and related
+services, such as JDBC and JPA resource providers.</p>
+<p>The Transaction Control Service (RFC-221) is an in-progress RFC publicly
available from the OSGi
+Alliance: <a
href="https://github.com/osgi/design/blob/master/rfcs/rfc0221/rfc-0221-TransactionControl.pdf">https://github.com/osgi/design/blob/master/rfcs/rfc0221/rfc-0221-TransactionControl.pdf</a></p>
+<p>Given that the RFC is non-final the OSGi API declared in this project is
subject to change at any time up
+to its official release. Also the behaviour of this implementation may not
always be up-to-date with the
+latest wording in the RFC. The project maintainers will, however try to keep
pace with the RFC, and to
+ensure that the implementations are compliant with any OSGi specifications
that result from the RFC.</p>
<h1 id="getting-started">Getting started<a class="headerlink"
href="#getting-started" title="Permanent link">¶</a></h1>
<p>If you're new to the Transaction Control service then we recommend that you
read the <a href="tx-control/quickstart.html">quickstart documentation
first</a>.</p>
<p>More detailed documentation is available in the <a
href="tx-control/index.html">Aries Transaction Control Project</a></p>
<h2 id="modules">Modules<a class="headerlink" href="#modules" title="Permanent
link">¶</a></h2>
<p>The following modules are available for use in OSGi</p>
<ol>
-<li>tx-control-service-local :- A purely local transaction control service
implementation. This can be used with any resource-local capable
ResourceProvider</li>
-<li>tx-control-service-xa :- An XA-capable transaction control service
implementation based on the Geronimo Transaction Manager. This can be used with
XA capable resources, or with local resources. Local resources will make use of
the last-participant gambit.</li>
-<li>tx-control-provider-jdbc-local :- A JDBC resource provider that can
integrate with local transactions. The JDBCConnectionProviderFactory service
may be used directly, or a service may be configured using the
<em>org.apache.aries.tx.control.jdbc.local</em> pid</li>
-<li>tx-control-provider-jdbc-xa :- A JDBC resource provider that can integrate
with local or XA transactions. The JDBCConnectionProviderFactory service may be
used directly, or a service may be configured using the
<em>org.apache.aries.tx.control.jdbc.xa</em> pid</li>
+<li>
+<p>tx-control-service-local :- A purely local transaction control service
implementation. This can be
+used with any resource-local capable ResourceProvider</p>
+</li>
+<li>
+<p>tx-control-service-xa :- An XA-capable transaction control service
implementation based on the
+Geronimo Transaction Manager. This can be used with XA capable resources, or
with local resources.
+Local resources will make use of the last-participant gambit.</p>
+</li>
+<li>
+<p>tx-control-provider-jdbc-local :- A JDBC resource provider that can
integrate with local transactions.
+The JDBCConnectionProviderFactory service may be used directly, or a service
may be configured using
+the <em>org.apache.aries.tx.control.jdbc.local</em> pid</p>
+</li>
+<li>
+<p>tx-control-provider-jdbc-xa :- A JDBC resource provider that can integrate
with local or XA transactions.
+The JDBCConnectionProviderFactory service may be used directly, or a service
may be configured using
+the <em>org.apache.aries.tx.control.jdbc.xa</em> pid</p>
+</li>
</ol>
<h3 id="which-modules-should-i-use">Which modules should I use?<a
class="headerlink" href="#which-modules-should-i-use" title="Permanent
link">¶</a></h3>
-<p>If you wish to use entirely lightweight, resource-local transactions then
it is best to pair the tx-control-service-local and
tx-control-provider-jdbc-local or tx-control-provider-jpa-local bundles. This
will give transactional behaviour, but the result is <em>not guaranteed to be
ACID if more than one resource is used</em>.</p>
-<p>If two-phase commit is needed across multiple resources then the
tx-control-service-xa <em>must</em> be used. and tx-control-provider-jdbc-xa or
tx-control-provider-jpa-xa bundles should be used.</p>
-<p><strong>DO NOT</strong> use both tx-control-service-xa and
tx-control-service-local at the same time. This will be confusing, and will
lead to problems if different parts of the runtime bind to different service
implementations.</p>
-<p>There is also no reason to use the tx-control-provider-jdbc-local in
addition to the tx-control-provider-jdbc-xa service. Using both together is not
typically harmful, however the tx-control-provider-jdbc-xa bundle supports all
of the same features as the tx-control-provider-jdbc-local bundle.</p></div>
+<p>If you wish to use entirely lightweight, resource-local transactions then
it is best to pair the
+tx-control-service-local and tx-control-provider-jdbc-local or
tx-control-provider-jpa-local bundles.
+This will give transactional behaviour, but the result is <em>not guaranteed
to be ACID if more than one
+resource is used</em>.</p>
+<p>If ACID behaviour is needed across multiple resources then the
tx-control-service-xa <em>must</em> be used.
+This service also provides an XA enabled two-phase commit algorithm, and also
allows for ACID
+behaviour when <em>one</em> of the resources only supports local transactions
by using the last participant gambit.</p>
+<p>When using the XA Transaction control service then the
tx-control-provider-jdbc-xa or
+tx-control-provider-jpa-xa resource provider bundles should be used.</p>
+<p><strong>IT IS NOT RECOMMENDED</strong> to use both tx-control-service-xa
and tx-control-service-local at
+the same time. This will be confusing, and may lead to problems if different
parts of the application
+bind to different service implementations.</p>
+<p>There is also no reason to use the tx-control-provider-jdbc-local in
addition to the
+tx-control-provider-jdbc-xa service. Using both together is not typically
harmful, however the
+tx-control-provider-jdbc-xa bundle supports all of the same features as the
+tx-control-provider-jdbc-local bundle.</p>
+<h2 id="pre-release-apis">Pre-release APIs<a class="headerlink"
href="#pre-release-apis" title="Permanent link">¶</a></h2>
+<p>As part of the Aries Transaction Control implementations pre-release
versions of the OSGi Transaction Control
+API are provided. Rather than putting the API into the wrong package
namespace, or outputting them at the wrong
+version, they will be exported with a mandatory attribute of
<code>api.status=aries.prerelease</code>. </p>
+<p>By setting this attribute on their API imports users accept that the API
may change without a change to the
+package version(s). These changes may, or may not, be binary compatible. Once
the specification is final the
+attribute will be removed from the export.</p></div>
<!-- Content -->
</td>
</tr>