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