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) > > <a>when user passes connection in DAS() and also sets ConnectionInfo > > -datasource/drivermanager - specify that passed connection will be used > and > > config connection will be ignored. > > > > <b>DAS 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 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. > > > > > > > > > > > > > > ___________________________________________________________________________________________________ > > > > > 1>testUserUnableToControlExternallyInitedTransaction > > > > > 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. > > > > > > > > > > > > > > _____________________________________________________________________________________________________ > > > > > 2>testUnableToCommitTransaction > > > > > 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. > > > > > > > > > _______________________________________________________________________________________________________ > > > > > > > > > > 3>testDataIntegrityViolation > > > > > > > > > > Scenario:- Bank account money transter > > > > > 0) Account1 original balance $10000, 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 > less > > > , > > > > > but > > > > > account2 is not $200+. So he lost $200 in network crash. This > viloates > > > > > data > > > > > integrity. > > > > > > > > > > Note: To simulate network failure cuasing SQLException, in DAS > code, > > > > > when > > > > > update command is issued for account2 a hardcoded SQLException is > > > > > thrown. > > > > > This code change is done just for testing purpose and will be > reverted > > > > > back. > > > > > > > > > > Regards, > > > > > Amita > > > > > > > > > > On 8/15/07, haleh mahbod < [EMAIL PROTECTED] > wrote: > > > > > > > > > > > > Amita, > > > > > > Maybe I am not getting this. What is the user case scenario that > you > > > > > are > > > > > > trying to cover with your suggestion (I understand what you are > > > > > suggesting > > > > > > to do, but not sure of use case)? In what case client needs > what > > > you > > > > > are > > > > > > mentioning, beyond what is provided today? > > > > > > > > > > > > Thanks for the clarification. > > > > > > Haleh > > > > > > > > > > > > On 8/14/07, Adriano Crestani < [EMAIL PROTECTED]> > wrote: > > > > > > > > > > > > > > ------->if DAS exposes connection thru getConnection() ONLY > when > > > > > > > managedtx=false, it need to control cases when managedtx=true. > So > > > 2. > > > > > > > > > > > will > > > > > > > be > > > > > > > needed. > > > > > > > If it exposes getConnection() ALWAYS (ignoring managetx), then > > > > > managedtx > > > > > > > > > > > > > loses its meaning and DAS can not control any transaction as > > > client > > > > > > always > > > > > > > have the control. > > > > > > > > > > > > > > I agree with you Amita, however the user will always have the > > > > > control > > > > > > when > > > > > > > it passes the a Connection to DAS on its creation no matter if > the > > > > > > > managedtx > > > > > > > is true or not, because he will have a reference to the > Connection > > > > > he > > > > > > > created. > > > > > > > > > > > > > > So, if the managedtx=true and the user passed the Connection > to > > > DAS, > > > > > it > > > > > > > will > > > > > > > make no sense not to expose the Connection to the user, since > he > > > > > already > > > > > > > > > > > > > has > > > > > > > its reference. > > > > > > > > > > > > > > Regards, > > > > > > > Adriano Crestani > > > > > > > > > > > > > > On 8/14/07, Amita Vadhavkar < [EMAIL PROTECTED]> > wrote: > > > > > > > > > > > > > > > > On 8/14/07, Adriano Crestani < [EMAIL PROTECTED]> > > > wrote: > > > > > > > > > > > > > > > > > > Here is my opinion: > > > > > > > > > > > > > > > > > > 1- There are 2 ways for user to provide a Connection to > DAS, > > > > > create > > > > > > > one > > > > > > > > > and > > > > > > > > > pass it to DAS on its creation or on ConnectionInfo. The > first > > > > > case > > > > > > is > > > > > > > > > already giving the access to the Connection to the user. > On > > > the > > > > > > > second, > > > > > > > > I > > > > > > > > > think it's useful to provide access to it with > > > getConnection(), > > > > > > since > > > > > > > > the > > > > > > > > > user wouldn't be able to manage the transacions if he > defines > > > > > the > > > > > > > > > managedtx=false. > > > > > > > > > > > > > > > > > > > > > > > > ------->if DAS exposes connection thru getConnection() ONLY > when > > > > > > > > managedtx=false, it need to control cases when > managedtx=true. > > > So > > > > > 2. > > > > > > > will > > > > > > > > be > > > > > > > > needed. > > > > > > > > If it exposes getConnection() ALWAYS (ignoring managetx), > then > > > > > > managedtx > > > > > > > > loses its meaning and DAS can not control any transaction as > > > > > client > > > > > > > always > > > > > > > > have the control. > > > > > > > > > > > > > > > > 2- Now, about start/endTransaction() methods, I agree with > > > > > Luciano, it > > > > > > > > will > > > > > > > > > look like DAS was specially designed for RDB when you > define > > > it > > > > > on > > > > > > DAS > > > > > > > > > class, maybe it could probably be added to rdb.DASImplclass > > > and > > > > > the > > > > > > > > user > > > > > > > > > would have to cast it to rdb.DASImpl when creating a DAS > > > > > instance > > > > > > > using > > > > > > > > > the > > > > > > > > > factory. > > > > > > > > > > > > > > > > > > Anyway, I don't agree with adding these methods, once if > being > > > > > > exposed > > > > > > > > the > > > > > > > > > > > > > > > > > > Connection with getConnection the user can commit or > rollback > > > > > > whenever > > > > > > > > he > > > > > > > > > wants, and control how many commands will be grouped as > atomic > > > > > > change > > > > > > > on > > > > > > > > > rdb > > > > > > > > > or not. > > > > > > > > > > > > > > > > > > 3- As we are already talking about DAS being heterogeneus > and > > > > > > > > independent > > > > > > > > > of > > > > > > > > > implementations, as a interface should be, the classes on > das > > > > > > package > > > > > > > > > shouldn't be depedent of das.rdb package classes. But on > patch > > > > > from > > > > > > > > > JIRA-1465 were added the methods > > > add/remove/get/ResultDescriptor > > > > > on > > > > > > > > > Command > > > > > > > > > class, however these methods are, as far as I know, only > > > > > intended to > > > > > > > > > > > > > be > > > > > > > > > used > > > > > > > > > with RDB DAS. So I think they are misplaced, maybe they > should > > > > > be > > > > > > > placed > > > > > > > > > on > > > > > > > > > a Command implementation under das.rdb package. What do > you > > > > > > 2 think? > > > > > > > > > > > > > > > > > > > > > > > > ----------->-This can be a good start for DAS API-Impl > > > separation > > > > > > work. > > > > > > > We > > > > > > > > can discuss > > > > > > > > what all changes that need to happen in current DAS (Luciano > > > > > already > > > > > > has > > > > > > > > some work in sandbox) to make a clean separation between API > and > > > > > Impl. > > > > > > > e.g > > > > > > > > . > > > > > > > > DAS interface does not have an API for connecting to > non-DBMS > > > data > > > > > > > stores, > > > > > > > > but it accepts java.sql.Connection indicating DAS from > Interface > > > > > level > > > > > > > > itself is tied to Database. Can we open another thread > > > > > > and list/discuss > > > > > > > > all > > > > > > > > the changes around this separation work? > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Adriano Crestani > > > > > > > > > > > > > > > > > > On 8/14/07, Amita Vadhavkar < [EMAIL PROTECTED]> > > > wrote: > > > > > > > > > > > > > > > > > > > > Just looked more at the code and found something more > > > > > interesting > > > > > > - > > > > > > > :) > > > > > > > > > > > > > > > > > > > > When there is no connectionInfo in DAS Config, managedtx > > > > > defaults > > > > > > to > > > > > > > > > true, > > > > > > > > > > so when > > > > > > > > > > connection is passed by user (as in TransactionTests), > > > > > managedtx > > > > > > is > > > > > > > > > true. > > > > > > > > > > > > > > > > > > > > So, with the current code case 4) can not occur (which > is > > > > > actually > > > > > > > > > > > > > > > useful) > > > > > > > > > > 4)false from caller DAS does not issue > > > > > > > > commit/rollback, > > > > > > > > > > external caller manages > > > > > > > > > > > > > > > > > > > > TransactionTests - if you look closely, there is just > "one" > > > > > > > > > > DAS.applyChanges(root) > > > > > > > > > > command > > > > > > > > > > which has 2 INSERT statements using same PK. So, 2nd > INSERT > > > > > gives > > > > > > > JDBC > > > > > > > > > > Exception > > > > > > > > > > and DAS uses it to issue rollback. So, TransactionTests > is > > > > > > > succedding > > > > > > > > in > > > > > > > > > > getting exception > > > > > > > > > > and avoiding "both" INSERTs due to the fact that "both > > > INSERTs > > > > > are > > > > > > > > under > > > > > > > > > > > > > > > > > > > same applyChanges() Command." > > > > > > > > > > > > > > > > > > > > What will happen in case when there is a client code > like > > > > > > > > > > das.applyChanges (root1); > > > > > > > > > > das.applyChanges(root2); > > > > > > > > > > and the client wants both applyChanges() to be part of > the > > > > > same > > > > > > > > > > transaction? > > > > > > > > > > Is it possible with current DAS? > > > > > > > > > > > > > > > > > > > > Based on the current code, there will be autocommits for > > > each > > > > > > > > > > applyChanges() which may > > > > > > > > > > not be desirable. Or is DAS forcing clients to grab all > > > > > changes > > > > > > > > somehow > > > > > > > > > in > > > > > > > > > > one call > > > > > > > > > > to das.applyChanges () to ensure transactional > integrity? Is > > > > > this > > > > > > > > > > convenient? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ___________________________________________________________________________ > > > > > > > > > > > > > > > > > > > > I could not understand the below statement - please > > > elaborate. > > > > > > > > > > ["In the case where client code requires access to the > > > > > connection, > > > > > > > is > > > > > > > > > > there any issue with supplying it to DAS ?'} > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ___________________________________________________________________________ > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Amita > > > > > > > > > > > > > > > > > > > > On 8/14/07, Luciano Resende < [EMAIL PROTECTED]> > wrote: > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > 1>When false, DAS.getConnection() should be > exposed > > > > > and > > > > > > user > > > > > > > > > > should > > > > > > > > > > > be > > > > > > > > > > > > > > allowed to handle transactions. DAS should not > issue > > > > > any > > > > > > > > > > > > > commits/rollbacks > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2>When 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > Luciano Resende > > > > > > > > > > > > > Apache Tuscany Committer > > > > > > > > > > > > > http://people.apache.org/~lresende< > > > http://people.apache.org/%7Elresende> > > > > > <http://people.apache.org/%7Elresende> > > > > > > < > > > > > > > > http://people.apache.org/%7Elresende > > > > > > > > > > <http://people.apache.org/%7Elresende > > > > > > > > > > > > > > http://lresende.blogspot.com/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > > To unsubscribe, e-mail: > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > For additional commands, e-mail: > > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Luciano Resende > > > > > > > > > > > Apache Tuscany Committer > > > > > > > > > > > http://people.apache.org/~lresende< > > > http://people.apache.org/%7Elresende> > > > > > <http://people.apache.org/%7Elresende> > > > > > > < > > > > > > > > http://people.apache.org/%7Elresende > > > > > > > > > > < http://people.apache.org/%7Elresende> > > > > > > > > > > > http://lresende.blogspot.com/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > 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] > >
