2016/05/28 - Apache Tuscany has been retired.

As this topic involves a lot of discussion thought the better place will be wiki.

I was just thinking randomly to see how to integrate the work in JIRA-1816 with the work
in JIRA-1700(implementation.das support for tx inents/policies). Below are some suggestions I could gather,
but need lot of feedback and ideas.

TransactionManager support in SCA (JIRA-1816)

---------------------------------------------------------------------------------------------------------------------------------
TransactionInfo - can have 2 subclasses - GlobalTransactionInfo (XADataSource...), LocalTransactionInfo (Connection...)
we can rename TransactionInfo to TransactionContext if it suits.

TransactionManager - also can have 2 similar flavours - LocalTransactionManager (what is there in the transaction.zip today)
and GlobalTransactionManager. GlobalTransactionManager can support say a class level annotation - @TransactionManagerFactory(Geronimo)
to have a way to inject an externally available TransactionManager like Geronimo, JOTM etc.
---------------------------------------------------------------------------------------------------------------------------------

Tx Policy Support in implementation.das (JIRA-1700)

----------------------------------------------------------------------------------------------------------------------------------------------
I went through the Tx Policy Draft and trying to understand it in detail. Below trying to give examples of different scenarions
for implementation.das and attempting to analyze just some part from that. Getting lost in different places . Need all possible comments.
I am just gathering all points below, with some discussions can prepare a design doc if that helps.

(RM=Resource Manager) (xads = XADataSource) (xares=XAResource)(conn=connection)(2PC - 2 Phase Commit)
----------------------------------------------------------------------------------------------------------------------------------------------
Note:
a> It is possible that the caller (say junit test case) passes XADataSource(which has Connection and XAResource) OR same can be obtained from
within SCA runtime.
b> At das.implementation level intents can be - managedTransaction.global, managedTransaction.local, noManagedTransaction, (still not clear why to support unqualified managedTransaction)
c> At present, implementation.das does not support oneWayInvocation - so need not consider transactedOneWay and immediateOneWay - is this right assumption?
d> At service level intents can be - propagatesTransaction, suspendsTransaction
----------------------------------------------------------------------------------------------------------------------------------------------
Scenarios:-

CASE1) 1 component - 1 impl - 1 connection info - multiple services - multiple operations/service

so at the time of createInvoker() for a service, the SCArutime can know both the intents (impl and interaction) and decide how to act on it.
i.e. during DASImplementationProvider.createInvoker().

1 impl == 1 RM (multiple Connections/XAConnections).
so multiple services in the same .composite will use the same RM

In DASImplementationProvider(component, impl) we have DASImplementationProvider.createInvoker(service, operation)
One DASImplementationProvider has 1 DataAccessEngineManager. Bue each createInvoker() has a new DASInvoker() with new das
and new DataAccessEngine. So each new invoker() will have a diff das instance.

example

scaDomain = SCADomain.newInstance("company.composite");
dasCompanyService = scaDomain.getService(CompanyService.class, "CompanyComponent/CompanyServiceComponent");

dasCustomerService = scaDomain.getService(CustomerService.class, "CompanyComponent/CustomerServiceComponent");

dasCompanyService.updateCompanies();//RM0 - das0
dasCustomerService.updateCustomers();//RM0 - das1
----------------------------------------------------------------------------------------------------------------------------------------------
CASE2) also there can be - multiple RMs (multiple XAConnections for Tx support for atomic tx, if atomic is not needed can use java.sql.Connections)

scaDomain1 = SCADomain.newInstance("company.composite");
dasCompanyService = scaDomain.getService(CompanyService.class, "CompanyComponent/CompanyServiceComponent");

scaDomain2 = SCADomain.newInstance("customer.composite");
dasCustomerService = scaDomain.getService(CustomerService.class, "CustomerComponent/CustomerServiceComponent");

dasCompanyService.updateCompanies(); //RM1 - das1
dasCustomerService.updateCustomers(); //RM2 - das2
----------------------------------------------------------------------------------------------------------------------------------------------
CASE3) case when at least one das (say das1) instance has a config with managedtx=true (i.e. das manages tx)
In this case the configs and intents of all other das instances are immeterial, because to support managedtx=true (for das1), all others will need
to follow the same mode.
----------------------------------------------------------------------------------------------------------------------------------------------
CASE4) case when non-DBMS RMs are involved

scaDomain1 = SCADomain.newInstance("company.composite");
dasCompanyService = scaDomain.getService(CompanyService.class, "CompanyComponent/CompanyServiceComponent");

scaDomain2 = SCADomain.newInstance("jmscustomer.composite");
jmsCustomerService = scaDomain.getService(jmsCustomerService.class, "jmsCustomerComponent/jmsCustomerServiceComponent");

dasCompanyService.updateCompanies(); //RM1 DBMS
jmsCustomerService.updateCustomers(); //RM2 JMS
--------------------------------------------------------------------------------------------------------------------------------------------------
The Table2 from Tx Policy Draft needs to be considered.

As the knowledge about das.implemnetation intent is at the construction of DASImplementationProvider(), but the knowledge of service level intent
is at DASImplementationProvider.createInvoke() level, createInvoker() is the place which can take decision about tx control.

The ConnectionInfo - finally present inside das (may it be from config.xml or .composite) should be in accordance with what is expected in the
effective intents.

DataAccessImplementationProvider.createInvoker() when calls getDAS() should pass as IN params the effective intents.

When caller wants to pass xads (in case of global tx)/connection (in case of local tx), it needs a way to inject it (i.e. inject tx context) in
the service. Some possible ways -
**All DAS based services - can say mandatorily have a method setTransactionContext(Object ctx) (ctx can be Connection/XADS based on local
or global). This should be invoked by the caller before calling any business method for the service.
**Another way, from JIRA-1816 work - say the caller does
GlobalTransactionContext.setContext(XADS) OR LocalTransactionContext.setContext(Connection).
with this the thread context will have info to be used inside SCA component/services.
DataAccessImplementationProvider will do getContext() and if it is available (i.e. caller did setContext), will pass it to the getDAS(),
so das instance will get Connection during construction.

---------------------------------------------------------------------------------------------------------------------------------------------------
I] propagatesTransaction + managedTransaction.global

MEANING: caller will ideally start tx and pass the tx context to sca runtime. the tx is distributed xa tx.

FLOW:
i) during DataAccessImplementationProvider.createInvoker()

, inents will be passed in as well as necessary info from
txn context will be passed in by DataAccessImplementationProvider.
ii) das will get constructed with passing "new" connection to FACTORY.createDAS(). Also set managedtx=false to enalble non-das tx management.

the caller will be responsible to handle the txn (i.e. managed shared global txn pattern)

example

XADS= GlobalTransactionManager.getXADataSource(pass in properties);
GlobalTransactionContext.setContext(XADS tied to XID); //due to threadlocal, this context is referenceable by DataAccessImplementationProvider now.
GlobalTransactionManager.begin(GlobalTransactionContext.getContext());

scaDomain = SCADomain.newInstance("company.composite");
dasCompanyService = scaDomain.getService(CompanyService.class, "CompanyComponent/CompanyServiceComponent");//needs XADS1 tied with same XID

dasCustomerService = scaDomain.getService(CustomerService.class, "CompanyComponent/CustomerServiceComponent");//needs XADS2 tied with same XID

dasCompanyService.updateCompanies();//RM0 - das0
dasCustomerService.updateCustomers();//RM0 - das1

GlobalTransactionManager.commit(context);//see that XID has 2 XADS tied to it and does necessaty actions for 2PC
--------------------------------------------------------------------------------------------------------------------------------------------------
Now for the case that, the caller is not having a ongoing tx and so does not inject tx context in sca runtime.

When DASImplementationProvider detects there is no tx context set , inside createInvoker(), it can first instantiate das without a connection
(some changes needed in tuscany-das-rdb for this), and then use das.getConfig() to get necessary config props and construct a tx context
to be used by the current DASInvoker. Say we create a new DASTransactionCoordinator() for this work.

DASTransactionCoordinator {

GlobalTransactionContext setTxContext(dasConfig)

//multiple XADS will need to be tied to single xid to make them part of 1 xa tx.
//more methods here for getContext, enqueXAResourceInXID, dqueue XAResource from XID, XID based 2PhaseCommit...
}

and will also pass "new" conection from the tx context to each new das instance.

Also DASImplementationProvider() in this case will need to terminate tx. This can be done in stop() of DASImplementationProvider();
start() can not be used to start a tx as at that time, there is no existing tx context.

Questions:
Now are my confusions. In DASImplementationProvider.stop() what is the way to know whether to commit/rollback? i.e. how stop() method will know about the invoke() having exceptions? Or otherwise each DASinvoker will need access to xid which is shared by all XAResources in the global tx
and the DASInvoker is supposed to call DASTransactionCoordinator.rollback() for case of exception?

Also, this whole story relates to only one RuntimeComponent (i.e. multiple services and multiple operations in each services but all in same
component. Thus the tx can be encompassed by DASImplementationProvider.) What to do for the case when the global tx needs to span multiple
components?
------------------------------------------------------------------------------------------------------------------------------------------------
II] suspendsTransaction + managedTransaction.global
Here even if caller has a tx, it will be ignored and DASImplementationProvider+DASTransactionCoordinator will create a new Tx context and
will manage tx. Same questions as I]
-------------------------------------------------------------------------------------------------------------------------------------------------
III] suspendsTransaction + managedTransaction.local

DASImplementationProvider() will pass DASConfig.connectionInfo() to LocalTransactionManager.getDataSource() and setContext() to get
java.sql.Connection (can be DriverManager or DataSource - in case of DataSource, the external env. is responsible for the JNDI initialization.)
(As local tx, no question of XADS). Same question - how to communicate exception occuring in DASInvoker.invoke() to stop()?
to decide whether to commit/rollback? Also as these are mere Connections and not XID/XADS etc. is it better for the DASInvoker() to control
the commit/rollback of tx? i.e. each DASInvoker() thread will be a Local Tx.
--------------------------------------------------------------------------------------------------------------------------------------------------
IV] suspendsTransaction + noManagedTransaction
this is equivalent to a das config with managedtx=true.

Now say in case, there are das1 and das2 involved from 2 different .composites in a caller's business method
and das1 has IV] / managedtx=true and das2 has I], how will we be able to dectate that , because das1 is das managed tx, das2 should behave in
same way?
-------------------------------------------------------------------------------------------------------------------------------------------------
Also, need to specify behavior for cases when only impl intent is present or only interaction intent is present.

CASE2) and CASE4) in case of I] need the caller to manage tx. If this is not happening, how implementation.das will be able to manage tx
(if there are multiple components involved)