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