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
Hi, I have tried to use JOTM and Tomcat and would like to create a sample web app in DAS showing how external transaction manager can control DAS transactions. I am creating another mail thread for any discussion for this sample + JOTM issues. We can demonstrate through this and accompanying wiki - how Txn support in DAS for externally managed txns should do. Regards, Amita On 8/17/07, Luciano Resende [EMAIL PROTECTED] wrote: By doing a quick debug on Amita's testcase from JIRA-1543, looks like we might have some bugs in our current code, that might be causing this whole confusion. Let me spend couple hours on this over the weekend, and send some feedback after that. I'll also write a wiki page with what I think the Transaction support should do/work. On 8/17/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Just trying to see what changes will be needed (marked with ) 1) when connection from user, and he wants to delegate transaction control to DAS, allow it only per/Command. This will save user from issuing one commit/rollback per command in the client code. (i.e. current way of managetx=true default, connection passed from user). So this is as of today, no changes needed. 2) when connection from user and user wants to control single/group of commands, he should set managedtx=false. -As default managedtx=true, user in this case will need to put ConnectionInfo element in config just for the sake of passing managedtx=false Giving new test case showing this 3)-- fix logic of DASImpl.managingConnections() - should just look at managedtx 4) when connection from DAS and user wants to control single/group of commands, he should set managedtx=false --- new test cases showing manage single/group of Commands 5)DAS will expose getConnection() for all cases except when connection by DAS, tx management by DAS --public Connection DAS.getConnection(); For exception case throw RuntimeException from DAS - DAS is controlling transaction, can not expose Connection! 5) awhen user passes connection in DAS() and also sets ConnectionInfo -datasource/drivermanager - specify that passed connection will be used and config connection will be ignored. bDAS can manage connection only when it is created internally and only/Command. i.e. DAS does not support internally managing transactions for group of commands -- Document - FAQs? 6) DAS throws RuntimeException with embedded SQLException - may it be connection closed, integrity violation etc. ---no changes needed I will submit patch for JIRA-1466 using above summary shortly. Regards, Amita On 8/17/07, Adriano Crestani [EMAIL PROTECTED] wrote: forwarding last message to dev list... On 8/17/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi Amita, thanks for the examples, it always helps to clarify : ). My comments: Use Case 1: I think if there is part of the code the user needs to control the transaction directly, he would never set the managedtx=true, that's why managedtx is an option, to give a chance to the user decide if he wants or not to control anytime the transaction. So, on my opinion it's an user error that set the managedtx as true when he wants to control the transaction, and not a DAS error. I understand that your point is try to avoid a user mistake like this, although the user needs to know well what the DAS interface does or not, and on this case the DAS interface says: DAS will control the transactions when you set managedtx=true. This kind of user mistake could be easily resolved if a Connection object could be easily copied, but as far as I know it can't. Use Case 2: Here I agree that not to expose the Connection when its created by DAS and managedtx is false is a DAS mistake. That's why I vote to expose getConnection and I see no problem to throw some kind of exception when user tries to invoke getConnection when managedtx=true. Use Case 3: a) About user invoking closeConnection, it's the same case I described on Use Case 1's comments, the user needs to be aware that DAS is controlling the transactions. However, DAS should throw some kind of exception when the Connection is closed externally, I don't know if it's doing that. b) If exposing the getConnection, I do not see anything new in using these new methods, start/endTransactions, that user cannot perform only using a Connection object. c) About data integrity, I think it's also wrong decision if the user set the managedtx=true if he may further want to perform a rollback on the db. In conclusion: +1 for exposing getConnection - for adding methods startTransaction and endTranscation Regards, Adriano Crestani On 8/16/07,
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]
Re: [DAS] Transaction support
Just trying to see what changes will be needed (marked with ) 1) when connection from user, and he wants to delegate transaction control to DAS, allow it only per/Command. This will save user from issuing one commit/rollback per command in the client code. (i.e. current way of managetx=true default, connection passed from user). So this is as of today, no changes needed. 2) when connection from user and user wants to control single/group of commands, he should set managedtx=false. -As default managedtx=true, user in this case will need to put ConnectionInfo element in config just for the sake of passing managedtx=false Giving new test case showing this 3)-- fix logic of DASImpl.managingConnections() - should just look at managedtx 4) when connection from DAS and user wants to control single/group of commands, he should set managedtx=false --- new test cases showing manage single/group of Commands 5)DAS will expose getConnection() for all cases except when connection by DAS, tx management by DAS --public Connection DAS.getConnection(); For exception case throw RuntimeException from DAS - DAS is controlling transaction, can not expose Connection! 5) awhen user passes connection in DAS() and also sets ConnectionInfo -datasource/drivermanager - specify that passed connection will be used and config connection will be ignored. bDAS can manage connection only when it is created internally and only/Command. i.e. DAS does not support internally managing transactions for group of commands -- Document - FAQs? 6) DAS throws RuntimeException with embedded SQLException - may it be connection closed, integrity violation etc. ---no changes needed I will submit patch for JIRA-1466 using above summary shortly. Regards, Amita On 8/17/07, Adriano Crestani [EMAIL PROTECTED] wrote: forwarding last message to dev list... On 8/17/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi Amita, thanks for the examples, it always helps to clarify : ). My comments: Use Case 1: I think if there is part of the code the user needs to control the transaction directly, he would never set the managedtx=true, that's why managedtx is an option, to give a chance to the user decide if he wants or not to control anytime the transaction. So, on my opinion it's an user error that set the managedtx as true when he wants to control the transaction, and not a DAS error. I understand that your point is try to avoid a user mistake like this, although the user needs to know well what the DAS interface does or not, and on this case the DAS interface says: DAS will control the transactions when you set managedtx=true. This kind of user mistake could be easily resolved if a Connection object could be easily copied, but as far as I know it can't. Use Case 2: Here I agree that not to expose the Connection when its created by DAS and managedtx is false is a DAS mistake. That's why I vote to expose getConnection and I see no problem to throw some kind of exception when user tries to invoke getConnection when managedtx=true. Use Case 3: a) About user invoking closeConnection, it's the same case I described on Use Case 1's comments, the user needs to be aware that DAS is controlling the transactions. However, DAS should throw some kind of exception when the Connection is closed externally, I don't know if it's doing that. b) If exposing the getConnection, I do not see anything new in using these new methods, start/endTransactions, that user cannot perform only using a Connection object. c) About data integrity, I think it's also wrong decision if the user set the managedtx=true if he may further want to perform a rollback on the db. In conclusion: +1 for exposing getConnection - for adding methods startTransaction and endTranscation Regards, Adriano Crestani On 8/16/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi Haleh, Please see all the use case details below. There are three user cases going wrong which I am trying to fix. I have created a JIRA-1543 to demonstrate with examples how DAS is failing in these use case scenarios. Patch contains 3 new test cases as below in TransactionTests.java. So far TransactionTests.java had only 1 test case and was not enough to uncover these issues. 1) when user passes connection to DAS, it is obvious that user is always going to have a handle to it and so the only option should be to make user control the transaction. Current DAS code issues commit/rollback / Command for this case, which is an erroneous behavior. Due to this user loses its ability to group commands based on business need in a transaction. ---check testUserUnableToControlExternallyInitedTransaction() 2) when managedtx=false and connection is created by DAS, NEITHER DAS NOR USER issue any commit/rollback ANYTIME. This is equaly
Re: [DAS] Transaction support
By doing a quick debug on Amita's testcase from JIRA-1543, looks like we might have some bugs in our current code, that might be causing this whole confusion. Let me spend couple hours on this over the weekend, and send some feedback after that. I'll also write a wiki page with what I think the Transaction support should do/work. On 8/17/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Just trying to see what changes will be needed (marked with ) 1) when connection from user, and he wants to delegate transaction control to DAS, allow it only per/Command. This will save user from issuing one commit/rollback per command in the client code. (i.e. current way of managetx=true default, connection passed from user). So this is as of today, no changes needed. 2) when connection from user and user wants to control single/group of commands, he should set managedtx=false. -As default managedtx=true, user in this case will need to put ConnectionInfo element in config just for the sake of passing managedtx=false Giving new test case showing this 3)-- fix logic of DASImpl.managingConnections() - should just look at managedtx 4) when connection from DAS and user wants to control single/group of commands, he should set managedtx=false --- new test cases showing manage single/group of Commands 5)DAS will expose getConnection() for all cases except when connection by DAS, tx management by DAS --public Connection DAS.getConnection(); For exception case throw RuntimeException from DAS - DAS is controlling transaction, can not expose Connection! 5) awhen user passes connection in DAS() and also sets ConnectionInfo -datasource/drivermanager - specify that passed connection will be used and config connection will be ignored. bDAS can manage connection only when it is created internally and only/Command. i.e. DAS does not support internally managing transactions for group of commands -- Document - FAQs? 6) DAS throws RuntimeException with embedded SQLException - may it be connection closed, integrity violation etc. ---no changes needed I will submit patch for JIRA-1466 using above summary shortly. Regards, Amita On 8/17/07, Adriano Crestani [EMAIL PROTECTED] wrote: forwarding last message to dev list... On 8/17/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi Amita, thanks for the examples, it always helps to clarify : ). My comments: Use Case 1: I think if there is part of the code the user needs to control the transaction directly, he would never set the managedtx=true, that's why managedtx is an option, to give a chance to the user decide if he wants or not to control anytime the transaction. So, on my opinion it's an user error that set the managedtx as true when he wants to control the transaction, and not a DAS error. I understand that your point is try to avoid a user mistake like this, although the user needs to know well what the DAS interface does or not, and on this case the DAS interface says: DAS will control the transactions when you set managedtx=true. This kind of user mistake could be easily resolved if a Connection object could be easily copied, but as far as I know it can't. Use Case 2: Here I agree that not to expose the Connection when its created by DAS and managedtx is false is a DAS mistake. That's why I vote to expose getConnection and I see no problem to throw some kind of exception when user tries to invoke getConnection when managedtx=true. Use Case 3: a) About user invoking closeConnection, it's the same case I described on Use Case 1's comments, the user needs to be aware that DAS is controlling the transactions. However, DAS should throw some kind of exception when the Connection is closed externally, I don't know if it's doing that. b) If exposing the getConnection, I do not see anything new in using these new methods, start/endTransactions, that user cannot perform only using a Connection object. c) About data integrity, I think it's also wrong decision if the user set the managedtx=true if he may further want to perform a rollback on the db. In conclusion: +1 for exposing getConnection - for adding methods startTransaction and endTranscation Regards, Adriano Crestani On 8/16/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi Haleh, Please see all the use case details below. There are three user cases going wrong which I am trying to fix. I have created a JIRA-1543 to demonstrate with examples how DAS is failing in these use case scenarios. Patch contains 3 new test cases as below in TransactionTests.java. So far TransactionTests.java had only 1 test case and was not enough to uncover these issues. 1) when user passes connection to DAS, it is obvious that user is always
Re: [DAS] Transaction support
Hi Haleh, Please see all the use case details below. There are three user cases going wrong which I am trying to fix. I have created a JIRA-1543 to demonstrate with examples how DAS is failing in these use case scenarios. Patch contains 3 new test cases as below in TransactionTests.java. So far TransactionTests.java had only 1 test case and was not enough to uncover these issues. 1) when user passes connection to DAS, it is obvious that user is always going to have a handle to it and so the only option should be to make user control the transaction. Current DAS code issues commit/rollback / Command for this case, which is an erroneous behavior. Due to this user loses its ability to group commands based on business need in a transaction. ---check testUserUnableToControlExternallyInitedTransaction() 2) when managedtx=false and connection is created by DAS, NEITHER DAS NOR USER issue any commit/rollback ANYTIME. This is equaly wrong. This way the Transaction control is at the mercy of How DBMS behaves upon close of a connection. This can be corrected if getConnection() is exposed. ---check testUnableToCommitTransaction() 3) most important-data integrity violation! When managedtx=true and Connection is created by DAS, and there are multiple applyChanges() which need to be in same transaction to ensure data integrity, DAS fails completely. Here exposing getConnection() won't do, as with this user can even issue closeConnection() and DAS will not function with that. Instead, if startTransaction(), endTransaction() are exposed, user will be able to maintain data integrity based on his demand. ---check testDataIntegrityViolation() ___ Alternative approach will be remove managedtx attribute itself from config.xsd and let user do whatever he wants with the connection, in this case just making sure user has handle to connection (either because he created it or because of getConnection()) will be enough. i.e. always delegate transaction control to the caller and don't handle it in DAS. ___ 1testUserUnableToControlExternallyInitedTransaction Scenario:- Stopped Employee department transfer 0) John Jones is in Advanced Technologies(Department1) 1) John Jones is removed from Advanced Technologies 2) User decides to revert the decision and rollsback the transaction Ideally, it is expected that remove from Department1 (1)) should not have happened and John Jones should still be in Department1. What is found in the end result is John Jones is removed from Department1 even though user has issued rollback. _ 2testUnableToCommitTransaction Scenario:- Employee department transfer 0) John Jones is in Advanced Technologies(Department1) 1) John Jones is removed from Advanced Technologies 2) John Jones is added to New Technologies(Department2) DAS Config has ConnectionInfo specified and user does not pass Connection to DAS. Thus Connection is created by DAS and used in Commands. Also, in DAS Config ConnectionInfo, managedtx=FALSE is set by user. This signals DAS to stop issuing any commit/rollback. Also, as Connection is internally formed by DAS and not exposed to user, there is no way user can handle commit/rollback. After , 0), 1), 2), user assumes that change has happened and John Jones is removed from Department1 and added to Department2. He creates a new Connection and a new DAS instance and checks data in database. When he issues query using new connection and new DAS ., he gets SQLException indicating lock could not be obtained on tables of interest and query could not go thru. This is because 1),2) are not commited by DAS nor user and so tables remained locked. ___ 3testDataIntegrityViolation Scenario:- Bank account money transter 0) Account1 original balance $1, account2 original balance $500 1) user removes $200 from account1 2) user adds $200 into account2 DAS Config has ConnectionInfo specified and user does not pass Connection to DAS. Thus Connection is created by DAS and used in Commands. Also, in DAS Config ConnectionInfo, managedtx=TRUE is set by user. This signals DAS to issue commit/rollback/Command. Also, as Connection is internally formed by DAS and not exposed to user, there is no way user can handle commit/rollback. After , 0), 1), there is a network crash during 2) and so 2) does not go thru, but on the other hand there is a SQLException thrown during 2) due to which DAS attempts a rollback. Now what is expected is 1) and 2) should both be rolled back, and account1 and account2 should have old balaces. This will ensure data integrity. When user checks data in DBMS, what is found is account1 is $200
Re: [DAS] Transaction support
-When connection is provider by caller(say container), there is no meaning of managedtx attribute, and it is better to let the caller handle the transactionality of the operations. So, when DAS is instantiated using external connection - mandate managedtx = false. Also, expose getConnection() from DAS to give a ref. of the connection (User already owns it, DAS is just providing ref.). DAS will not issue any commit/rollback -When connection is created internally, managedtx has a meaning. 1When false, DAS.getConnection() should be exposed and user should be allowed to handle transactions. DAS should not issue any commits/rollbacks 2When true, do not expose DAS.getConnection(). If TRANSACTION_DEMARCATION_PER_COMMAND is true, work like today (commit /rollback per command). If TRANSACTION_DEMARCATION_PER_COMMAND is false (now is time for DAS to manager group of commands as a sigle transaction).Here, DAS at the simplest can use a static FLAG set/unset using methods - void DAS.startTransaction(), //mark FLAG to set - void DAS.endTransaction(commit/rollback). //mark FLAG to reset endTransaction() will issue commit/rollback based on arg passed to it. For any exception condition DAS will issue rollback() on transaction and will reset the FLAG. Client needs to call start/endTransaction() for group of Commands. Also, here for timeout impelmentation, Java Timer can be used. Regards, Amita On 8/10/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi Amita, I think it can be useful to bunch commands, but I didn't get how you are planning to do it : ( What would be the parameter of method getTransaction? Regards, Adriano Crestani On 7/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Below is a simple matrix based on current RDB DAS Config, showing what it does/does not do today managedtx(default-true) - config attribute in ConnectionInfo element to control transactions managedtx database conn. supplied effect on transaction -- 1)true from caller each DAS command undergoes commit/rollback 2)false from within DAS this is not handled in any way 3)true from within DAS each DAS command undergoes commit/rollback 4)false from caller DAS does not issue commit/rollback, external caller manages Case 2) - when database Connection is created in RDB DAS, it does not expose it to caller today. So, in case 2) neither RDB DAS nor caller can manage transactions. From above, it seems that, RDB DAS in general does not provide support to handle a group of Commands under one database transactions. Only case 4) is the place when multiple DAS Commands can undergo as one transaction. To help serve the transaction control better, I would like to propose the following requirements:- [1]RDB DAS should have a way to issue commit/rollback for single/group of Commands [2]When there is exception, the ongoing transaction should be immediately aborted by RDB DAS irrespective of whether it was for single/group of Commands [3]Optional Timeout feature - to have an escape route to end the transaction controlled by RDB DAS, when it seems to linger for time Timeout (to take care of situations like deadlocks). For this, I am thinking of introducing 2 new attributes in RDB DAS Config A) TRANSACTION_DEMARCATION_PER_COMMAND - true/false (mandatory when managedtx=true) B) TRANSACTION_TIMEOUT - millis (always optional) These 2 attributes can be specified at Config level. When case 1) or 3) - both these attributes will take effect. When 2) or 4), these will be ignored. To handle case 2) - here user is required to be given handle to the database Connection, created by RDB DAS (in 1) and 3), this should be prohibited, and in 4) user already has handle of the Connection.) This way, the responsibility of transaction management can be taken by user for 4)(as it is today) and 2)(as now user will get handle) For 1) and 3) - TRANSACTION_DEMARCATION_PER_COMMAND=true is already working in RDB DAS today. For handling TRANSACTION_DEMARCATION_PER_COMMAND=false, new APIs can be given to user like DAS.getTransaction().commit() /rollback() , so in a controlled way, user will be able to bunch group of Commands based on business logic and issue commits/rollbacks. Also, internally, RDB DAS will be responsible to rollback in case of exceptions and in case of Timeouts. Please share your thoughts. Regards, Amita On 6/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, I just want to clarify if the below is something missing in DAS or just that I have not understood it clearly. Appreciate your response.
Re: [DAS] Transaction support
I think that the main goal of DAS, is to be an heterogeneous API that could be used to implement support for various backends (rdb, ldap, xml etc). Starting to add various semantics that might be specific to RDB might take us out of this direction. So, for this issue, let's take a step back and think around the scenarios where this new enhancement might be useful, could you please list a couple here ? It would be great if you could also mention the deficiencies you found from managedtx parameter on each scenario. Also, couple questions : - Could you please elaborate more on why you need to expose DAS.getConnection() ? - If you already defined the transaction demarcation flags, why you still ask the client code to handle start/endTransaction? Why is that different from passing managedtx = false ? On 8/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: -When connection is provider by caller(say container), there is no meaning of managedtx attribute, and it is better to let the caller handle the transactionality of the operations. So, when DAS is instantiated using external connection - mandate managedtx = false. Also, expose getConnection() from DAS to give a ref. of the connection (User already owns it, DAS is just providing ref.). DAS will not issue any commit/rollback -When connection is created internally, managedtx has a meaning. 1When false, DAS.getConnection() should be exposed and user should be allowed to handle transactions. DAS should not issue any commits/rollbacks 2When true, do not expose DAS.getConnection(). If TRANSACTION_DEMARCATION_PER_COMMAND is true, work like today (commit /rollback per command). If TRANSACTION_DEMARCATION_PER_COMMAND is false (now is time for DAS to manager group of commands as a sigle transaction).Here, DAS at the simplest can use a static FLAG set/unset using methods - void DAS.startTransaction(), //mark FLAG to set - void DAS.endTransaction(commit/rollback). //mark FLAG to reset endTransaction() will issue commit/rollback based on arg passed to it. For any exception condition DAS will issue rollback() on transaction and will reset the FLAG. Client needs to call start/endTransaction() for group of Commands. Also, here for timeout impelmentation, Java Timer can be used. Regards, Amita On 8/10/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi Amita, I think it can be useful to bunch commands, but I didn't get how you are planning to do it : ( What would be the parameter of method getTransaction? Regards, Adriano Crestani On 7/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Below is a simple matrix based on current RDB DAS Config, showing what it does/does not do today managedtx(default-true) - config attribute in ConnectionInfo element to control transactions managedtx database conn. supplied effect on transaction -- 1)true from caller each DAS command undergoes commit/rollback 2)false from within DAS this is not handled in any way 3)true from within DAS each DAS command undergoes commit/rollback 4)false from caller DAS does not issue commit/rollback, external caller manages Case 2) - when database Connection is created in RDB DAS, it does not expose it to caller today. So, in case 2) neither RDB DAS nor caller can manage transactions. From above, it seems that, RDB DAS in general does not provide support to handle a group of Commands under one database transactions. Only case 4) is the place when multiple DAS Commands can undergo as one transaction. To help serve the transaction control better, I would like to propose the following requirements:- [1]RDB DAS should have a way to issue commit/rollback for single/group of Commands [2]When there is exception, the ongoing transaction should be immediately aborted by RDB DAS irrespective of whether it was for single/group of Commands [3]Optional Timeout feature - to have an escape route to end the transaction controlled by RDB DAS, when it seems to linger for time Timeout (to take care of situations like deadlocks). For this, I am thinking of introducing 2 new attributes in RDB DAS Config A) TRANSACTION_DEMARCATION_PER_COMMAND - true/false (mandatory when managedtx=true) B) TRANSACTION_TIMEOUT - millis (always optional) These 2 attributes can be specified at Config level. When case 1) or 3) - both these attributes will take effect. When 2) or 4), these will be ignored. To handle case 2) - here user is required to be given handle to the database Connection, created by RDB DAS (in 1) and 3), this
Re: [DAS] Transaction support
Comments inline
On 8/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Below is what is happening today:-
managedtx(default-true) - config attribute in ConnectionInfo element to
control transactions
managedtx database conn. supplied effect on transaction
--
1)true from caller each DAS command undergoes
commit/rollback
2)false from within DAS this is not handled in any way
3)true from within DAS each DAS command undergoes
commit/rollback
4)false from caller DAS does not issue
commit/rollback, external caller manages
So what is lacking is
a ability to issue commit/rollback on group of commands where connection is
managed by DAS (managedtx=true).(case 3)). this will be essential to handle
any business unit work. otherwise DAS is ending up today in mimicking
autocommit behavior of Database which is not so useful when business
transactions need to handle a group of operations as one atomic unit
So, the test case below is an example of multiple commands under one
transaction. On this scenario, connection is supplied by client, and I
think this gives you the same results as if the connection was created
by DAS and exposed to client code, and also gives more flexibility to
how the client will aquire the connection, or re-use some other
connection to be part of the same transaction.
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test/TransactionTests.java
b what is the reason behind providing case 1)? when client/container
provides connection, it can be controlled by client/container. and even if
DAS tries to controll it, as user has handle to connection,
commits/rollbacks can be issued by client async with what DAS is trying to
control. So there will be no meaning in DAS controlling the connection
supplied by client. And so there is no meaning to managedtx either.
c case 2), as of today there is no way to expose connection to client when
it is created by DAS. so neither DAS nor client manages transaction. For
this case exposing connection thru getConnection() will be useful (for other
cases, it can be banned)
In the case where client code requires access to the connection, is
there any issue with supplying it to DAS ?
d as DAS is heterogeneous API, is the DAS config going to be
heterogeneous too? If yes, then it will be advantageousto support the
transactional nature of RDB using such semantics. If the backend (non RDB)
does not support transaction, this semantics will be of no use, but
in this case the DAS config can be different (more tuned to that particular
backend)
So, it all depends on whether we are following the path to support DAS with
heterogeneous APIs or not. Will you please elaborate meaning of
heterogeneous API in context of different flavors of DAS?
Yes, the idea is that each impl would define it's own model,
inheriting from a common root class (xsd element)
e {If you already defined the transaction demarcation flags...}Where are we
doing that at present? What is there is only issue commit/rollback at the
end of each DAS Command. Am I missing some other transaction demarcation
mechanism already available in DAS?
Regards,
Amita
On 8/13/07, Luciano Resende [EMAIL PROTECTED] wrote:
I think that the main goal of DAS, is to be an heterogeneous API that
could be used to implement support for various backends (rdb, ldap,
xml etc). Starting to add various semantics that might be specific to
RDB might take us out of this direction.
So, for this issue, let's take a step back and think around the
scenarios where this new enhancement might be useful, could you please
list a couple here ? It would be great if you could also mention the
deficiencies you found from managedtx parameter on each scenario.
Also, couple questions :
- Could you please elaborate more on why you need to expose
DAS.getConnection() ?
- If you already defined the transaction demarcation flags, why you
still ask the client code to handle start/endTransaction? Why is that
different from passing managedtx = false ?
On 8/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
-When connection is provider by caller(say container), there is no
meaning
of managedtx attribute, and it is better to let the caller handle the
transactionality of the operations. So, when DAS is instantiated using
external connection - mandate managedtx = false. Also, expose
getConnection() from DAS to give a ref. of the connection (User already
owns
it, DAS is just providing ref.). DAS will not issue any commit/rollback
-When connection is created internally, managedtx has a meaning.
1When false, DAS.getConnection() should be exposed and user should be
allowed to handle
Re: [DAS] Transaction support
Below is a simple matrix based on current RDB DAS Config, showing what it does/does not do today managedtx(default-true) - config attribute in ConnectionInfo element to control transactions managedtx database conn. supplied effect on transaction -- 1)true from caller each DAS command undergoes commit/rollback 2)false from within DAS this is not handled in any way 3)true from within DAS each DAS command undergoes commit/rollback 4)false from caller DAS does not issue commit/rollback, external caller manages Case 2) - when database Connection is created in RDB DAS, it does not expose it to caller today. So, in case 2) neither RDB DAS nor caller can manage transactions. From above, it seems that, RDB DAS in general does not provide support to handle a group of Commands under one database transactions. Only case 4) is the place when multiple DAS Commands can undergo as one transaction. To help serve the transaction control better, I would like to propose the following requirements:- [1]RDB DAS should have a way to issue commit/rollback for single/group of Commands [2]When there is exception, the ongoing transaction should be immediately aborted by RDB DAS irrespective of whether it was for single/group of Commands [3]Optional Timeout feature - to have an escape route to end the transaction controlled by RDB DAS, when it seems to linger for time Timeout (to take care of situations like deadlocks). For this, I am thinking of introducing 2 new attributes in RDB DAS Config A) TRANSACTION_DEMARCATION_PER_COMMAND - true/false (mandatory when managedtx=true) B) TRANSACTION_TIMEOUT - millis (always optional) These 2 attributes can be specified at Config level. When case 1) or 3) - both these attributes will take effect. When 2) or 4), these will be ignored. To handle case 2) - here user is required to be given handle to the database Connection, created by RDB DAS (in 1) and 3), this should be prohibited, and in 4) user already has handle of the Connection.) This way, the responsibility of transaction management can be taken by user for 4)(as it is today) and 2)(as now user will get handle) For 1) and 3) - TRANSACTION_DEMARCATION_PER_COMMAND=true is already working in RDB DAS today. For handling TRANSACTION_DEMARCATION_PER_COMMAND=false, new APIs can be given to user like DAS.getTransaction().commit() /rollback() , so in a controlled way, user will be able to bunch group of Commands based on business logic and issue commits/rollbacks. Also, internally, RDB DAS will be responsible to rollback in case of exceptions and in case of Timeouts. Please share your thoughts. Regards, Amita On 6/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, I just want to clarify if the below is something missing in DAS or just that I have not understood it clearly. Appreciate your response. At present, DAS has managedtx attribute at ConnectionInfo level(default true). So when true or not specificed, each Command does a database commit. When false, external caller is responsible for managing transaction. There is no way to bunch a set of Commands in one transaction under control of DAS, it is at the mercy of external caller (when managedtx is false). Is it not useful to introduce this in DAS, wherein, when DAS manages transaction, it can have today's behavior (similar to autocommit) or can have a public API which allows client to commit using the connection associated with current DAS instance. This way, when the connection is not passed from client (but created in DAS, using ConnectionInfo and thus not exposed to client), client will have a way to support real transaction (multiple logical bunch of Commands) using DAS? Regards, Amita
