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.DASImpl class > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
