Hi,
I was the one who wrote the prototype using Geronimo Transaction Manager.
I'll check out the 2.x code to refresh my memory. The brief idea was the
following:
1) There are transaction intents to control the TX for both interaction and
implementation. The interaction ones denote whether the TX context should be
propagated or suspended. The implementation one controls if a Global TX, a
local TX, or no TX should be demarcated for the component implementation.
2) The intents are provided by a set of policySets which contains the TX
policies.
3) The policies are binding-specific, for example, binding.ws probably uses
WS-Atomic Transaction while others may use JTA.
4) Tuscany registers provider factories for the TX policies. The provider
either inserts an interceptor to enforce the TX behavior by delegating to
the TM APIs.
5) Binding Provider (or interceptor added to the binding invocation chain)
is responsible for interacting with the underlying protocol to propagate TX
context, such as WS-Atomic SOAP header or CORBA TX.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[email protected]>
Sent: Thursday, January 21, 2010 1:50 PM
To: "tuscany-dev" <[email protected]>
Subject: Copying policy from 1.x to 2.x
I just checked in a lightly touched version of policy transaction from
1.x. It's another policy to consider as we fill in the gaps in the
policy support. I realize this wasn't 100% complete in 1.x. Not sure
who did this work originally but would be useful to have a quick run
through of the design. In particular there's an interesting
relationship between the original intents, the "Actions" and then the
transaction intents within the module. Be interested to understand
more about that.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
