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
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
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]
