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://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://lresende.blogspot.com/ > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > >
