Re: [DAS] Transaction support - a bigger picture question
Attempting to describe basic steps/changes I am trying to 1support policies/intents and 2external connection passing in DAS. These two need to go together, as trying transaction(y/n) intent at present and for this to test, need ability to support passing db connection from component impl to DAS instance. - Requirements:(specific to implementation.das) - 1) intents and policies can be defined at implementation level. With this one implementation.das gets tied to one set of policies defined in das.compositeat assembly time. So to use same DAS config with different set of policies, another component with another implementation.das is required. implementation.das will ignore intents and policies defined at any other level (at least for the time being) To begin with only 2 intents are experimented with a transaction (tx controlled by SCA runtime), b noTransaction (tx controlled by DAS) e.g. composite xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; targetNamespace=http://sample/das; name=das component name=DASServiceComponentExtTxn tuscany:implementation.das config=/CompanyConfig.xml dataAccessType=rdb requires=transaction tuscany:connectionInfo tuscany:connectionProperties driverClass=org.apache.derby.jdbc.EmbeddedDriver databaseURL=jdbc:derby:target/test-classes/dastest; create = true loginTimeout=60/ /tuscany:connectionInfo /tuscany:implementation.das /component component name=DASServiceComponentDASTxn tuscany:implementation.das config=/CompanyConfig.xml dataAccessType=rdb requires=noTransaction tuscany:connectionInfo tuscany:connectionProperties driverClass=org.apache.derby.jdbc.EmbeddedDriver databaseURL=jdbc:derby:target/test-classes/dastest; create = true loginTimeout=60/ /tuscany:connectionInfo /tuscany:implementation.das /component /composite - 2) At present, implementation.das has provision to define connectionInfo which helps DAS to create and manage Connection and Txn internally. (equiv. managedtx=true). This is eqiv. to intent b noTransaction. In order to support intent a transaction, (equiv. managedtx=false), implementation.das needs a way to pass external connection to DAS instance. Details of DAS Txn control - http://incubator.apache.org/tuscany/rdb-das-transaction-control.html. The externally passed Connection can be JDBC or JTA. Also a JDBC connection can come from DriverManager or DataSource. implementation.das needs to support all of this. - 3) validations: There is a possibility that the DAS Config (may it be a separate file like one from above example CompanyConfig.xml or may it be the info passed from das.composite to DAS instance through tuscany:connectionInfo) , there is a chance that there can be conflicts in the DAS Config and intent/policies. e.g. intent=transaction, managedtx=true(or absent which means true -as it is the default value) OR intent=noTransaction, managedtx=false. For such conflicts, I am throwing different exceptions at present. Will this be the right thing to do or is it better to define some overriding logic (like intents have higher priority over DAS Config ...Suggestions?) so I am trying to throw exceptions for below cases a DAS Config (dasconfig.xml/das.composite portion) has ConnectionInfo with either ConnectionProps or DataSource and intent=transaction Exception: DAS is internally managing Connection/Transaction, can not support intent transaction b Both , dasconfig.xml and das.composite provide ConnectionInfo Exception: ConnectionInfo defined in multiple places. c DAS Config has managedtx=true, das.composite has intent=transaction Exception: Intent and DAS Config in conflict:- Intent transaction can not be supported when DAS manages connection/transaction internally d DAS Config has managedtx=false, das.composite has intent=noTransaction Exception: Intent and DAS Config in conflict:- Intent noTransaction can not be supported when DAS does not manage connection/transaction internally e intent=transaction and DAS Config has not defined managedtx (so default true) Exception: When intent=transaction, DAS Config needs to explicitly define managedtx=false f It is acceptable if intent=noTransaction(and managedtx=true) and connection is passed to DAS from SCA Runtime, the user needs to ensure that DAS alone is managing Txn
Re: [DAS] Transaction support - a bigger picture question
Hi, I have given this a try based on what I tried in JIRA-1665 (Sample Using JOTM with DAS) Here also I am using JOTM with SCA+DAS. Currently played with 2 simple intents: a transaction (Tx management from External TM), b noTransaction (Tx management from DAS) The only changes needed are as below:- A tuscany-data-engine-helper:- 1)DataAccessEngineManager new method getDAS(String config, ConnectionInfo connectionInfo, ListIntent intents, ListPolicySet policySets) Here if intent atransaction is detected, ConnectionInfo.setManagedTx(false) will be called. This modified connnectionInfo will be passed through configHelper to the new DAS instance. This way if external TM is going to manage Tx, DAS is signaled for it. And logic to support this method 2) ConnectionInfo new attribute managedtx with setter/getter B tuscany-implementation-das 1) DASImplementation implements PolicyAttachPoint 2) DASImplementationProcessor read(reader) - will read policies and intents on DASImplementation from .composite 3) DASImplementationProvider createInvoker() will call getDAS(passing config, connectioninfo, intents, policies) same will be for createCallbackInvoker() With these above changes and with setup similar to JIRA-1665 sample, I could see that the external connection is being used by DAS (naming service is resolving datasource properly). The point I am stuck at is, in RDB-DAS, when we use external DS, we do not pass userName, password. But MYSQL (which with InnoDB supports Txn and works well with JOTM) does need id, pwd in ds.getConnection(). This can be case with other DBs as well. So, it looks like DAS config.xsd needs to allow passing userName, password in ConnectionInfo too ( and not just for ConnectionProperties). Thus below will be the changed DAS config portion:- xsd:complexType name=ConnectionInfo xsd:sequence xsd:element maxOccurs=1 minOccurs=0 name=ConnectionProperties type=config:ConnectionProperties/ /xsd:sequence xsd:attribute name=dataSource type=xsd:string/ xsd:attribute name=managedtx type=xsd:boolean default=true/ xsd:attribute name=userName type=xsd:string default=/ xsd:attribute name=password type=xsd:string default=/ /xsd:complexType xsd:complexType name=ConnectionProperties xsd:attribute name=driverClass type=xsd:string/ xsd:attribute name=databaseURL type=xsd:string/ xsd:attribute name=loginTimeout type=xsd:int default=0/ /xsd:complexType Suggestion? If this looks OK, I would like to make the above changes and create a sample in tuscany-implementation-das demoing use of intent and ext TM. Will give a try with geronimo as well. Regards, Amita On 9/2/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Luciano Resende wrote: I guess your suggestion for starting simple is fine, and I guess implementation.das could get integrated with SCA Policy and DAS would have the necessary support, unless we find some bugs on the DAS side. I'll see if I can get to this in the coming weeks... BTW, what transaction manager are we going to use in Tuscany ? Do we have any today ? Two suggestions: - in a standalone environment, use JOTM [1] - in Geronimo, get the TM from Geronimo, as done in the Tuscany/Geronimo plugin at [2] [1] http://jotm.objectweb.org/ [2] http://svn.apache.org/repos/asf/geronimo/plugins/tuscany -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Transaction support - a bigger picture question
Hey, very good, some comments inline One question that I have is regarding the Transaction Manager, who is responsible for creating the transaction manager ? The SCA runtime, or implementations ? In the case of SCA runtime, we need to investigate that part, but I guess we can start by having it under the implementation as a proof of concept for now. On 9/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, I have given this a try based on what I tried in JIRA-1665 (Sample Using JOTM with DAS) Here also I am using JOTM with SCA+DAS. Currently played with 2 simple intents: I think we are going to use geronimo transaction manager with SCA integration, and there is a sample on implementation.bepel on how to use it, it's very simple, could you try using that one ? a transaction (Tx management from External TM), b noTransaction (Tx management from DAS) The only changes needed are as below:- A tuscany-data-engine-helper:- 1)DataAccessEngineManager new method getDAS(String config, ConnectionInfo connectionInfo, ListIntent intents, ListPolicySet policySets) Here if intent atransaction is detected, ConnectionInfo.setManagedTx(false) will be called. This modified connnectionInfo will be passed through configHelper to the new DAS instance. This way if external TM is going to manage Tx, DAS is signaled for it. Great... I'll leave comments on the policy side to Venkat or Sebastien or others that have been playing on this area... And logic to support this method 2) ConnectionInfo new attribute managedtx with setter/getter Ok B tuscany-implementation-das 1) DASImplementation implements PolicyAttachPoint 2) DASImplementationProcessor read(reader) - will read policies and intents on DASImplementation from .composite Who should read here, implementation.das or we should delegate to the policy artifact processors ? 3) DASImplementationProvider createInvoker() will call getDAS(passing config, connectioninfo, intents, policies) same will be for createCallbackInvoker() What other information you will need from intents and policies when creating DAS ? you already passed the managed transaction flag inside the connectionInfo, right ? Note that there is still support for a das config file, how are you going to manage that ? We probably need to throw an exception if DAS config file sets does NOT set the managed transaction flag, but transaction policy is set. With these above changes and with setup similar to JIRA-1665 sample, I could see that the external connection is being used by DAS (naming service is resolving datasource properly). The point I am stuck at is, in RDB-DAS, when we use external DS, we do not pass userName, password. But MYSQL (which with InnoDB supports Txn and works well with JOTM) does need id, pwd in ds.getConnection(). This can be case with other DBs as well. So, it looks like DAS config.xsd needs to allow passing userName, password in ConnectionInfo too ( and not just for ConnectionProperties). Thus below will be the changed DAS config portion:- xsd:complexType name=ConnectionInfo xsd:sequence xsd:element maxOccurs=1 minOccurs=0 name=ConnectionProperties type=config:ConnectionProperties/ /xsd:sequence xsd:attribute name=dataSource type=xsd:string/ xsd:attribute name=managedtx type=xsd:boolean default=true/ xsd:attribute name=userName type=xsd:string default=/ xsd:attribute name=password type=xsd:string default=/ /xsd:complexType xsd:complexType name=ConnectionProperties xsd:attribute name=driverClass type=xsd:string/ xsd:attribute name=databaseURL type=xsd:string/ xsd:attribute name=loginTimeout type=xsd:int default=0/ /xsd:complexType Create a DAS jira for this, and we can investigate further... Suggestion? If this looks OK, I would like to make the above changes and create a sample in tuscany-implementation-das demoing use of intent and ext TM. I have a demo in progress, probably is good to have a test case for now, and we could incorporate transaction support on the demo. Will give a try with geronimo as well. Regards, Amita On 9/2/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Luciano Resende wrote: I guess your suggestion for starting simple is fine, and I guess implementation.das could get integrated with SCA Policy and DAS would have the necessary support, unless we find some bugs on the DAS side. I'll see if I can get to this in the coming weeks... BTW, what transaction manager are we going to use in Tuscany ? Do we have any today ? Two suggestions: - in a standalone environment, use JOTM [1] - in Geronimo, get the TM from Geronimo, as done in the Tuscany/Geronimo plugin at [2] [1] http://jotm.objectweb.org/ [2] http://svn.apache.org/repos/asf/geronimo/plugins/tuscany -- Jean-Sebastien
Re: [DAS] Transaction support - a bigger picture question
[snip] Luciano Resende wrote: I guess your suggestion for starting simple is fine, and I guess implementation.das could get integrated with SCA Policy and DAS would have the necessary support, unless we find some bugs on the DAS side. I'll see if I can get to this in the coming weeks... BTW, what transaction manager are we going to use in Tuscany ? Do we have any today ? Two suggestions: - in a standalone environment, use JOTM [1] - in Geronimo, get the TM from Geronimo, as done in the Tuscany/Geronimo plugin at [2] [1] http://jotm.objectweb.org/ [2] http://svn.apache.org/repos/asf/geronimo/plugins/tuscany -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Transaction support - a bigger picture question
I guess your suggestion for starting simple is fine, and I guess implementation.das could get integrated with SCA Policy and DAS would have the necessary support, unless we find some bugs on the DAS side. I'll see if I can get to this in the coming weeks... BTW, what transaction manager are we going to use in Tuscany ? Do we have any today ? On 8/27/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Comments inline. [snip] Amita Vadhavkar wrote: I have not worked on the latest DAS-SCA integration so far, and am quite sure Lucinao will have good pointers in this area. But looking at the current tuscany-implementation-das, can see the following possible. Yes, I guess the idea is to: - access Data inside an SCA component declared with implementation-das - let the application developer annotate the component implementation and services with transaction policy intents to indicate what he wants in terms of transaction So take this as my attempt to understand intents/policySets and DAS-SCA integration :) DASImplementation implements org.apache.tuscany.sca.assembly.Implementationand contains org.apache.tuscany.sca.assembly.Service dasService. Using dasService, requiredIntents on the Service can be found. There are two categories of policy intents in SCA: - implementation policy intents - used to indicate requirements of the component implementation (authorization for example, i.e. you must be authorized to execute my implementation) - interaction policy intents - used to configure how a component will interact with others (confidentiality for example, i.e. messages exchanged with my component must be encrypted) I think that the same will have to apply to transactions as well, the DAS implementation will probably have to deal with intents specified on both services and the implementation itself. org.apache.tuscany.das.rdb.DAS interface can be enhanced to accept these intents. DAS internally can configure DASConfig reflecting the intents specified , so that DAS instance construction happens with correct attributes. Based on these attributes DAS transaction control will occur (if intent is TransactionControl). Intent TransactionControl can be qualified as say, 1) Container Transaction Control, 2) DAS Transaction Control. Can you describe this a bit more to help me understand what you mean by Container transaction control vs DAS transaction control? Advantage of having intent attached to a service will be, using different intents for different services of same component. Yes, different services - different interaction policies Questions: What will be the policySets here? Say, if policySet/intent Container Transaction Control mandates that the implementation should expose getConnection() so that container Runtime can use it, how this mandate can be achieved? Not sure at all yet. A PolicySet translates an Intent to the corresponding configuration of the underlying runtime, so it really depends on what the DAS + SCA runtime will expect. [snip] On 8/20/07, Mike Edwards [EMAIL PROTECTED] wrote: Folks, Sorry to cut across the discussion about Transaction support in DAS, but are folks aware of the proposal for Transaction support in SCA? which leads to the entertaining question of how the DAS transaction support relates to the SCA transaction support. The problem at the moment is that the SCA spec group only has an unpublished draft of the Transaction support spec. The intention is to publish an updated draft in the near future. However, I can say that the SCA spec mechanism is based on the use of Intents to apply transactional characteristics to SCA components. I've seen several exchanges on the list already from people interested in some support for transactions... So since the spec is not ready yet, how about starting now with something really simple like an implementation policy intent that would just say: - transaction - i.e. my implementation must run as part of a transaction - noTransaction - i.e. I don't want to run as part of a transaction It may look simplistic, but will help us understand the end to end story, work on the necessary plumbing and integration with a transaction manager etc. and we can always add more later and adjust the details of the intents and policySets when the spec is ready. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Transaction support - a bigger picture question
Comments inline. [snip] Amita Vadhavkar wrote: I have not worked on the latest DAS-SCA integration so far, and am quite sure Lucinao will have good pointers in this area. But looking at the current tuscany-implementation-das, can see the following possible. Yes, I guess the idea is to: - access Data inside an SCA component declared with implementation-das - let the application developer annotate the component implementation and services with transaction policy intents to indicate what he wants in terms of transaction So take this as my attempt to understand intents/policySets and DAS-SCA integration :) DASImplementation implements org.apache.tuscany.sca.assembly.Implementationand contains org.apache.tuscany.sca.assembly.Service dasService. Using dasService, requiredIntents on the Service can be found. There are two categories of policy intents in SCA: - implementation policy intents - used to indicate requirements of the component implementation (authorization for example, i.e. you must be authorized to execute my implementation) - interaction policy intents - used to configure how a component will interact with others (confidentiality for example, i.e. messages exchanged with my component must be encrypted) I think that the same will have to apply to transactions as well, the DAS implementation will probably have to deal with intents specified on both services and the implementation itself. org.apache.tuscany.das.rdb.DAS interface can be enhanced to accept these intents. DAS internally can configure DASConfig reflecting the intents specified , so that DAS instance construction happens with correct attributes. Based on these attributes DAS transaction control will occur (if intent is TransactionControl). Intent TransactionControl can be qualified as say, 1) Container Transaction Control, 2) DAS Transaction Control. Can you describe this a bit more to help me understand what you mean by Container transaction control vs DAS transaction control? Advantage of having intent attached to a service will be, using different intents for different services of same component. Yes, different services - different interaction policies Questions: What will be the policySets here? Say, if policySet/intent Container Transaction Control mandates that the implementation should expose getConnection() so that container Runtime can use it, how this mandate can be achieved? Not sure at all yet. A PolicySet translates an Intent to the corresponding configuration of the underlying runtime, so it really depends on what the DAS + SCA runtime will expect. [snip] On 8/20/07, Mike Edwards [EMAIL PROTECTED] wrote: Folks, Sorry to cut across the discussion about Transaction support in DAS, but are folks aware of the proposal for Transaction support in SCA? which leads to the entertaining question of how the DAS transaction support relates to the SCA transaction support. The problem at the moment is that the SCA spec group only has an unpublished draft of the Transaction support spec. The intention is to publish an updated draft in the near future. However, I can say that the SCA spec mechanism is based on the use of Intents to apply transactional characteristics to SCA components. I've seen several exchanges on the list already from people interested in some support for transactions... So since the spec is not ready yet, how about starting now with something really simple like an implementation policy intent that would just say: - transaction - i.e. my implementation must run as part of a transaction - noTransaction - i.e. I don't want to run as part of a transaction It may look simplistic, but will help us understand the end to end story, work on the necessary plumbing and integration with a transaction manager etc. and we can always add more later and adjust the details of the intents and policySets when the spec is ready. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Transaction support - a bigger picture question
I have not worked on the latest DAS-SCA integration so far, and am quite sure Lucinao will have good pointers in this area. But looking at the current tuscany-implementation-das, can see the following possible. So take this as my attempt to understand intents/policySets and DAS-SCA integration :) DASImplementation implements org.apache.tuscany.sca.assembly.Implementationand contains org.apache.tuscany.sca.assembly.Service dasService. Using dasService, requiredIntents on the Service can be found. org.apache.tuscany.das.rdb.DAS interface can be enhanced to accept these intents. DAS internally can configure DASConfig reflecting the intents specified , so that DAS instance construction happens with correct attributes. Based on these attributes DAS transaction control will occur (if intent is TransactionControl). Intent TransactionControl can be qualified as say, 1) Container Transaction Control, 2) DAS Transaction Control. Advantage of having intent attached to a service will be, using different intents for different services of same component. Questions: What will be the policySets here? Say, if policySet/intent Container Transaction Control mandates that the implementation should expose getConnection() so that container Runtime can use it, how this mandate can be achieved? When DAS is not running as part of SCA runtime, DAS Config will support required equiavalent attributes thru DAS Config. Regards, Amita On 8/21/07, haleh mahbod [EMAIL PROTECTED] wrote: Aligning the two transaction handling model makes sense specially when there is support for a generic DAS as an SCA service. There has been some discussions on DAS as a service on the mailing list in the past. On 8/20/07, Mike Edwards [EMAIL PROTECTED] wrote: Folks, Sorry to cut across the discussion about Transaction support in DAS, but are folks aware of the proposal for Transaction support in SCA? which leads to the entertaining question of how the DAS transaction support relates to the SCA transaction support. The problem at the moment is that the SCA spec group only has an unpublished draft of the Transaction support spec. The intention is to publish an updated draft in the near future. However, I can say that the SCA spec mechanism is based on the use of Intents to apply transactional characteristics to SCA components. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
