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