You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Amita Vadhavkar <am...@gmail.com> on 2007/07/12 08:00:18 UTC
Re: [DAS] Transaction support
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 <am...@gmail.com> 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
>
Re: [DAS] Transaction support
Posted by Amita Vadhavkar <am...@gmail.com>.
Hi,
I have tried to use JOTM and Tomcat and would like to create a sample web
app in
DAS showing how external transaction manager can control DAS transactions.
I am creating another mail thread for any discussion for this sample + JOTM
issues.
We can demonstrate through this and accompanying wiki - how Txn support in
DAS
for externally managed txns should do.
Regards,
Amita
On 8/17/07, Luciano Resende <lu...@gmail.com> wrote:
>
> 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 <am...@gmail.com> 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 <ad...@apache.org> wrote:
> > >
> > > forwarding last message to dev list...
> > >
> > > On 8/17/07, Adriano Crestani <ad...@apache.org> 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 <am...@gmail.com> 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 < hmahbod@gmail.com > 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 < adrianocrestani@apache.org>
> 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 < amita.vadhavkar@gmail.com>
> wrote:
> > > > > > > >
> > > > > > > > On 8/14/07, Adriano Crestani < adrianocrestani@apache.org>
> > > 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.DASImplclass
> > > 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 < amita.vadhavkar@gmail.com>
> > > 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 < luckbr1975@gmail.com>
> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Comments inline
> > > > > > > > > > >
> > > > > > > > > > > On 8/13/07, Amita Vadhavkar <
> amita.vadhavkar@gmail.com>
> > > > > 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 < luckbr1975@gmail.com >
> > > > > 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 <
> > > amita.vadhavkar@gmail.com>
> > > > > > > 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 <
> > > > > adrianocrestani@apache.org>
> > > > > > > > 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 <
> > > > > amita.vadhavkar@gmail.com>
> > > > > > > > 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 <
> > > > > > amita.vadhavkar@gmail.com>
> > > > > > > > > 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:
> > > > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > > > > > > > For additional commands, e-mail:
> > > > > > > tuscany-dev-help@ws.apache.org
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > 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:
> > > > > tuscany-user-unsubscribe@ws.apache.org
> > > > > > > > > > > For additional commands, e-mail:
> > > > > tuscany-user-help@ws.apache.org
> > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
Re: [DAS] Transaction support - a bigger picture question
Posted by Amita Vadhavkar <am...@gmail.com>.
Attempting to describe basic steps/changes I am trying to 1>support
policies/intents and
2>external connection passing in DAS. These two need to go together, as
trying
transaction(y/n) intent at present and for this to test, need ability to
support passing db
connection from component impl to DAS instance.
-----------------------------------------------------------------------------------------------------------------------------
Requirements:(specific to implementation.das) -
1) intents and policies can be defined at implementation level. With this
one
implementation.das gets tied to one set of policies defined in
das.compositeat assembly
time. So to use same DAS config with different set of policies, another
component with
another implementation.das is required. implementation.das will ignore
intents and policies
defined at any other level (at least for the time being)
To begin with only 2 intents are experimented with
a> transaction (tx controlled by SCA runtime), b> noTransaction (tx
controlled by DAS)
e.g.
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"
targetNamespace="http://sample/das"
name="das">
<component name="DASServiceComponentExtTxn">
<tuscany:implementation.das config="/CompanyConfig.xml"
dataAccessType="rdb"
requires="transaction">
<tuscany:connectionInfo>
<tuscany:connectionProperties
driverClass="org.apache.derby.jdbc.EmbeddedDriver"
databaseURL="jdbc:derby:target/test-classes/dastest; create =
true"
loginTimeout="600000"/>
</tuscany:connectionInfo>
</tuscany:implementation.das>
</component>
<component name="DASServiceComponentDASTxn">
<tuscany:implementation.das config="/CompanyConfig.xml"
dataAccessType="rdb"
requires="noTransaction">
<tuscany:connectionInfo>
<tuscany:connectionProperties
driverClass="org.apache.derby.jdbc.EmbeddedDriver"
databaseURL="jdbc:derby:target/test-classes/dastest; create =
true"
loginTimeout="600000"/>
</tuscany:connectionInfo>
</tuscany:implementation.das>
</component>
</composite>
-----------------------------------------------------------------------------------------------------------------------------
2) At present, implementation.das has provision to define connectionInfo
which helps DAS to
create and manage Connection and Txn internally. (equiv. managedtx=true).
This is eqiv. to
intent b> "noTransaction".
In order to support intent a> "transaction", (equiv. managedtx=false),
implementation.das needs a way to pass external connection to DAS instance.
Details of DAS Txn control -
http://incubator.apache.org/tuscany/rdb-das-transaction-control.html.
The externally passed Connection can be JDBC or JTA. Also a JDBC connection
can come from DriverManager or DataSource. implementation.das needs to
support all of this.
-----------------------------------------------------------------------------------------------------------------------------
3) validations:
There is a possibility that the DAS Config (may it be a separate file like
one from above
example CompanyConfig.xml or may it be the info passed from das.composite to
DAS instance through <tuscany:connectionInfo>) , there is a chance that
there can be conflicts
in the DAS Config and intent/policies.
e.g. intent=transaction, managedtx=true(or absent which means true -as it is
the default value)
OR
intent=noTransaction, managedtx=false.
For such conflicts, I am throwing different exceptions at present. Will this
be the right thing
to do or is it better to define some overriding logic (like intents have
higher priority over DAS Config ...Suggestions?)
so I am trying to throw exceptions for below cases
a> DAS Config (dasconfig.xml/das.composite portion) has ConnectionInfo with
either ConnectionProps or DataSource and intent=transaction
Exception: DAS is internally managing Connection/Transaction, can not
support intent "transaction"
b> Both , dasconfig.xml and das.composite provide ConnectionInfo
Exception: ConnectionInfo defined in multiple places.
c> DAS Config has managedtx=true, das.composite has intent="transaction"
Exception: Intent and DAS Config in conflict:- Intent "transaction" can not
be supported when DAS manages connection/transaction internally
d> DAS Config has managedtx=false, das.composite has intent="noTransaction"
Exception: Intent and DAS Config in conflict:- Intent "noTransaction" can
not be supported when DAS does not manage connection/transaction internally
e> intent=transaction and DAS Config has not defined managedtx (so default
true)
Exception: When intent="transaction", DAS Config needs to explicitly define
managedtx=false
f> It is acceptable if intent=noTransaction(and managedtx=true) and
connection is passed to DAS from SCA Runtime, the user needs to ensure that
DAS alone is managing Txn
-----------------------------------------------------------------------------------------------------------------------------
4) At present, the below 2 examples show that implementation.das (and
dasconfig.xml) support a way to provide connection info to DAS instance for
internally created/managed connection
e.g.
/*Driver Manager*/
<component name="DASServiceComponent" requires="transaction">
<tuscany:implementation.das config="/CompanyConfig.xml"
dataAccessType="rdb"
requires="transaction">
<tuscany:connectionInfo>
<tuscany:connectionProperties
driverClass="org.apache.derby.jdbc.EmbeddedDriver"
databaseURL="jdbc:derby:target/test-classes/dastest; create =
true"
loginTimeout="600000"/>
</tuscany:connectionInfo>
</tuscany:implementation.das>
</component>
/*DataSource*/
<component name="DASServiceComponent" requires="transaction">
<tuscany:implementation.das config="/CompanyConfig.xml"
dataAccessType="rdb"
requires="transaction">
<tuscany:connectionInfo datasource="mydsname">
</tuscany:connectionInfo>
</tuscany:implementation.das>
</component>
-----------------------------------------------------------------------------------------------------------------------------
But we need a way for the other option - pass external
(JDBC-DriverManager/DataSource OR JTA) connection to DAS instance.
For this I propose changes like below examples. This way it will be
consistent to the current design.
e.g.
Note: externalConnection=false by default
/*Driver Manager*/
<component name="DASServiceComponent" requires="transaction">
<tuscany:implementation.das config="/CompanyConfig.xml"
dataAccessType="rdb"
requires="transaction">
<tuscany:connectionInfo externalConnection="true"
mode="jdbc-driverManager">
<tuscany:connectionProperties
driverClass="org.apache.derby.jdbc.EmbeddedDriver"
databaseURL="jdbc:derby:target/test-classes/dastest; create =
true"
loginTimeout="600000"/>
</tuscany:connectionInfo>
</tuscany:implementation.das>
</component>
-----------------------------------------------------------------------------------------------------------------------------
Note:For below, the SCA runtime (by itself or from its container) should
have a JNDI Context entry for the datasource, das.implementation will look
it up and pass to DAS instance. At present attempting the same through a
test case.
/*DataSource*/
<component name="DASServiceComponent" requires="transaction">
<tuscany:implementation.das config="/CompanyConfig.xml"
dataAccessType="rdb"
requires="transaction">
<tuscany:connectionInfo datasource="mydsname"
externalConnection="true"
mode="jdbc-dataSource">
</tuscany:connectionInfo>
</tuscany:implementation.das>
</component>
-----------------------------------------------------------------------------------------------------------------------------
Note: For below assuming the SCA runtime should supply a Transaction Manager
instance
(like Geronimo) and implementation.das is responsible for using it by tying
a xaconnection
resource to the transaction support provided by TM. At present mimicing it
by having a small
package in tuscany-implementation-das for Geronimo Transaction Manager. This
can be obsoleted when the same is available from SCA runtime. Also, it is
seen that different XADataSource impls require diff set of setter methods,
so trying to keep it flexible.
e.g.
MySQL:
((MysqlXADataSource) xads).setUser(dbcfg.getConnectionInfo
().getConnectionProperties().getUserName());
((MysqlXADataSource) xads).setPassword(dbcfg.getConnectionInfo
().getConnectionProperties().getPassword());
((MysqlXADataSource) xads).setUrl(dbcfg.getConnectionInfo
().getConnectionProperties().getDatabaseURL());
Derby:
((EmbeddedXADataSource) xads).setCreateDatabase("create");
((EmbeddedXADataSource) xads).setDatabaseName("target/dastest");
/*XA*/
<component name="DASServiceComponent" requires="transaction">
<tuscany:implementation.das config="/CompanyConfig.xml"
dataAccessType="rdb"
requires="transaction">
<tuscany:connectionInfo datasource="mydsname"
externalConnection="true" mode="jta">
<tuscany:xaConnectionProperties
xaDataSouceClass="
com.mysql.jdbc.optional.xyz.MysqlXADataSource">
<tuscany:xaDataSourceConfig>
<tuscany:xaMethod name="setXXX" value="valXXX" />
<tuscany:xaMethod name="setYYY" value="valYYY" />
</tuscany:xaDataSourceConfig>
</tuscany:xaConnectionProperties>
</tuscany:connectionInfo>
</tuscany:implementation.das>
</component>
-----------------------------------------------------------------------------------------------------------------------------
Please give me all comments/feedback to refine the above.
regards,
amita
On 9/14/07, Luciano Resende <lu...@gmail.com> wrote:
>
> Hey, very good, some comments inline
>
> One question that I have is regarding the Transaction Manager, who is
> responsible for creating the transaction manager ? The SCA runtime, or
> implementations ? In the case of SCA runtime, we need to investigate
> that part, but I guess we can start by having it under the
> implementation as a proof of concept for now.
>
> On 9/13/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > Hi,
> > I have given this a try based on what I tried in JIRA-1665 (Sample Using
> > JOTM with DAS)
> > Here also I am using JOTM with SCA+DAS. Currently played with 2 simple
> > intents:
>
> I think we are going to use geronimo transaction manager with SCA
> integration, and there is a sample on implementation.bepel on how to
> use it, it's very simple, could you try using that one ?
>
> > a> transaction (Tx management from External TM), b> noTransaction (Tx
> > management from DAS)
> >
> > The only changes needed are as below:-
> > A> tuscany-data-engine-helper:-
> > 1)DataAccessEngineManager
> > new method getDAS(String config, ConnectionInfo connectionInfo,
> List<Intent>
> > intents, List<PolicySet> policySets)
> > Here if intent "a>transaction" is detected, ConnectionInfo.setManagedTx
> (false)
> > will be called.
> > This modified connnectionInfo will be passed through configHelper to the
> new
> > DAS instance.
> > This way if external TM is going to manage Tx, DAS is signaled for it.
> >
>
> Great... I'll leave comments on the policy side to Venkat or Sebastien
> or others that have been playing on this area...
>
> > And logic to support this method
> >
> > 2) ConnectionInfo
> > new attribute managedtx with setter/getter
> >
>
> Ok
>
> > B> tuscany-implementation-das
> > 1) DASImplementation implements PolicyAttachPoint
> >
> > 2) DASImplementationProcessor
> > read(reader) - will read policies and intents on DASImplementation from
> > .composite
> >
>
> Who should read here, implementation.das or we should delegate to the
> policy artifact processors ?
>
> Ans: it will be done by policy processor
> 3) DASImplementationProvider
> > createInvoker() will call getDAS(passing config, connectioninfo,
> intents,
> > policies)
> > same will be for createCallbackInvoker()
> >
>
> What other information you will need from intents and policies when
> creating DAS ? you already passed the managed transaction flag inside
> the connectionInfo, right ? Note that there is still support for a das
> config file, how are you going to manage that ? We probably need to
> throw an exception if DAS config file sets does NOT set the managed
> transaction flag, but transaction policy is set.
>
> > With these above changes and with setup similar to JIRA-1665 sample, I
> could
> > see
> > that the external connection is being used by DAS (naming service is
> > resolving
> > datasource properly).
> >
> > The point I am stuck at is, in RDB-DAS, when we use external DS, we do
> not
> > pass
> > userName, password. But MYSQL (which with InnoDB supports Txn and works
> well
> > with JOTM) does need id, pwd in ds.getConnection(). This can be case
> with
> > other DBs as well.
> >
> > So, it looks like DAS config.xsd needs to allow passing userName,
> password
> > in ConnectionInfo too ( and not just for ConnectionProperties).
> >
> > Thus below will be the changed DAS config portion:-
> > <xsd:complexType name="ConnectionInfo">
> > <xsd:sequence>
> > <xsd:element maxOccurs="1" minOccurs="0"
> > name="ConnectionProperties" type="config:ConnectionProperties"/>
> > </xsd:sequence>
> > <xsd:attribute name="dataSource" type="xsd:string"/>
> > <xsd:attribute name="managedtx" type="xsd:boolean"
> default="true"/>
> > <xsd:attribute name="userName" type="xsd:string" default=""/>
> > <xsd:attribute name="password" type="xsd:string" default=""/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="ConnectionProperties">
> > <xsd:attribute name="driverClass" type="xsd:string"/>
> > <xsd:attribute name="databaseURL" type="xsd:string"/>
> > <xsd:attribute name="loginTimeout" type="xsd:int"
> > default="0"/>
> > </xsd:complexType>
> >
>
> Create a DAS jira for this, and we can investigate further...
>
> > Suggestion? If this looks OK, I would like to make the above changes and
> > create a sample in tuscany-implementation-das demoing use of intent and
> ext
> > TM.
>
> I have a demo in progress, probably is good to have a test case for
> now, and we could incorporate transaction support on the demo.
>
> > Will give a try with geronimo as well.
>
>
> >
> > Regards,
> > Amita
> >
> > On 9/2/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > >
> > > [snip]
> > > Luciano Resende wrote:
> > > > I guess your suggestion for starting simple is fine, and I guess
> > > > implementation.das could get integrated with SCA Policy and DAS
> would
> > > > have the necessary support, unless we find some bugs on the DAS
> side.
> > > > I'll see if I can get to this in the coming weeks...
> > > >
> > > > BTW, what transaction manager are we going to use in Tuscany ? Do
> we
> > > > have any today ?
> > > >
> > >
> > > Two suggestions:
> > > - in a standalone environment, use JOTM [1]
> > > - in Geronimo, get the TM from Geronimo, as done in the
> Tuscany/Geronimo
> > > plugin at [2]
> > >
> > > [1] http://jotm.objectweb.org/
> > > [2] http://svn.apache.org/repos/asf/geronimo/plugins/tuscany
> > >
> > > --
> > > Jean-Sebastien
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
Re: [DAS] Transaction support - a bigger picture question
Posted by Amita Vadhavkar <am...@gmail.com>.
Attempting to describe basic steps/changes I am trying to 1>support
policies/intents and
2>external connection passing in DAS. These two need to go together, as
trying
transaction(y/n) intent at present and for this to test, need ability to
support passing db
connection from component impl to DAS instance.
-----------------------------------------------------------------------------------------------------------------------------
Requirements:(specific to implementation.das) -
1) intents and policies can be defined at implementation level. With this
one
implementation.das gets tied to one set of policies defined in
das.compositeat assembly
time. So to use same DAS config with different set of policies, another
component with
another implementation.das is required. implementation.das will ignore
intents and policies
defined at any other level (at least for the time being)
To begin with only 2 intents are experimented with
a> transaction (tx controlled by SCA runtime), b> noTransaction (tx
controlled by DAS)
e.g.
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"
targetNamespace="http://sample/das"
name="das">
<component name="DASServiceComponentExtTxn">
<tuscany:implementation.das config="/CompanyConfig.xml"
dataAccessType="rdb"
requires="transaction">
<tuscany:connectionInfo>
<tuscany:connectionProperties
driverClass="org.apache.derby.jdbc.EmbeddedDriver"
databaseURL="jdbc:derby:target/test-classes/dastest; create =
true"
loginTimeout="600000"/>
</tuscany:connectionInfo>
</tuscany:implementation.das>
</component>
<component name="DASServiceComponentDASTxn">
<tuscany:implementation.das config="/CompanyConfig.xml"
dataAccessType="rdb"
requires="noTransaction">
<tuscany:connectionInfo>
<tuscany:connectionProperties
driverClass="org.apache.derby.jdbc.EmbeddedDriver"
databaseURL="jdbc:derby:target/test-classes/dastest; create =
true"
loginTimeout="600000"/>
</tuscany:connectionInfo>
</tuscany:implementation.das>
</component>
</composite>
-----------------------------------------------------------------------------------------------------------------------------
2) At present, implementation.das has provision to define connectionInfo
which helps DAS to
create and manage Connection and Txn internally. (equiv. managedtx=true).
This is eqiv. to
intent b> "noTransaction".
In order to support intent a> "transaction", (equiv. managedtx=false),
implementation.das needs a way to pass external connection to DAS instance.
Details of DAS Txn control -
http://incubator.apache.org/tuscany/rdb-das-transaction-control.html.
The externally passed Connection can be JDBC or JTA. Also a JDBC connection
can come from DriverManager or DataSource. implementation.das needs to
support all of this.
-----------------------------------------------------------------------------------------------------------------------------
3) validations:
There is a possibility that the DAS Config (may it be a separate file like
one from above
example CompanyConfig.xml or may it be the info passed from das.composite to
DAS instance through <tuscany:connectionInfo>) , there is a chance that
there can be conflicts
in the DAS Config and intent/policies.
e.g. intent=transaction, managedtx=true(or absent which means true -as it is
the default value)
OR
intent=noTransaction, managedtx=false.
For such conflicts, I am throwing different exceptions at present. Will this
be the right thing
to do or is it better to define some overriding logic (like intents have
higher priority over DAS Config ...Suggestions?)
so I am trying to throw exceptions for below cases
a> DAS Config (dasconfig.xml/das.composite portion) has ConnectionInfo with
either ConnectionProps or DataSource and intent=transaction
Exception: DAS is internally managing Connection/Transaction, can not
support intent "transaction"
b> Both , dasconfig.xml and das.composite provide ConnectionInfo
Exception: ConnectionInfo defined in multiple places.
c> DAS Config has managedtx=true, das.composite has intent="transaction"
Exception: Intent and DAS Config in conflict:- Intent "transaction" can not
be supported when DAS manages connection/transaction internally
d> DAS Config has managedtx=false, das.composite has intent="noTransaction"
Exception: Intent and DAS Config in conflict:- Intent "noTransaction" can
not be supported when DAS does not manage connection/transaction internally
e> intent=transaction and DAS Config has not defined managedtx (so default
true)
Exception: When intent="transaction", DAS Config needs to explicitly define
managedtx=false
f> It is acceptable if intent=noTransaction(and managedtx=true) and
connection is passed to DAS from SCA Runtime, the user needs to ensure that
DAS alone is managing Txn
-----------------------------------------------------------------------------------------------------------------------------
4) At present, the below 2 examples show that implementation.das (and
dasconfig.xml) support a way to provide connection info to DAS instance for
internally created/managed connection
e.g.
/*Driver Manager*/
<component name="DASServiceComponent" requires="transaction">
<tuscany:implementation.das config="/CompanyConfig.xml"
dataAccessType="rdb"
requires="transaction">
<tuscany:connectionInfo>
<tuscany:connectionProperties
driverClass="org.apache.derby.jdbc.EmbeddedDriver"
databaseURL="jdbc:derby:target/test-classes/dastest; create =
true"
loginTimeout="600000"/>
</tuscany:connectionInfo>
</tuscany:implementation.das>
</component>
/*DataSource*/
<component name="DASServiceComponent" requires="transaction">
<tuscany:implementation.das config="/CompanyConfig.xml"
dataAccessType="rdb"
requires="transaction">
<tuscany:connectionInfo datasource="mydsname">
</tuscany:connectionInfo>
</tuscany:implementation.das>
</component>
-----------------------------------------------------------------------------------------------------------------------------
But we need a way for the other option - pass external
(JDBC-DriverManager/DataSource OR JTA) connection to DAS instance.
For this I propose changes like below examples. This way it will be
consistent to the current design.
e.g.
Note: externalConnection=false by default
/*Driver Manager*/
<component name="DASServiceComponent" requires="transaction">
<tuscany:implementation.das config="/CompanyConfig.xml"
dataAccessType="rdb"
requires="transaction">
<tuscany:connectionInfo externalConnection="true"
mode="jdbc-driverManager">
<tuscany:connectionProperties
driverClass="org.apache.derby.jdbc.EmbeddedDriver"
databaseURL="jdbc:derby:target/test-classes/dastest; create =
true"
loginTimeout="600000"/>
</tuscany:connectionInfo>
</tuscany:implementation.das>
</component>
-----------------------------------------------------------------------------------------------------------------------------
Note:For below, the SCA runtime (by itself or from its container) should
have a JNDI Context entry for the datasource, das.implementation will look
it up and pass to DAS instance. At present attempting the same through a
test case.
/*DataSource*/
<component name="DASServiceComponent" requires="transaction">
<tuscany:implementation.das config="/CompanyConfig.xml"
dataAccessType="rdb"
requires="transaction">
<tuscany:connectionInfo datasource="mydsname"
externalConnection="true"
mode="jdbc-dataSource">
</tuscany:connectionInfo>
</tuscany:implementation.das>
</component>
-----------------------------------------------------------------------------------------------------------------------------
Note: For below assuming the SCA runtime should supply a Transaction Manager
instance
(like Geronimo) and implementation.das is responsible for using it by tying
a xaconnection
resource to the transaction support provided by TM. At present mimicing it
by having a small
package in tuscany-implementation-das for Geronimo Transaction Manager. This
can be obsoleted when the same is available from SCA runtime. Also, it is
seen that different XADataSource impls require diff set of setter methods,
so trying to keep it flexible.
e.g.
MySQL:
((MysqlXADataSource) xads).setUser(dbcfg.getConnectionInfo
().getConnectionProperties().getUserName());
((MysqlXADataSource) xads).setPassword(dbcfg.getConnectionInfo
().getConnectionProperties().getPassword());
((MysqlXADataSource) xads).setUrl(dbcfg.getConnectionInfo
().getConnectionProperties().getDatabaseURL());
Derby:
((EmbeddedXADataSource) xads).setCreateDatabase("create");
((EmbeddedXADataSource) xads).setDatabaseName("target/dastest");
/*XA*/
<component name="DASServiceComponent" requires="transaction">
<tuscany:implementation.das config="/CompanyConfig.xml"
dataAccessType="rdb"
requires="transaction">
<tuscany:connectionInfo datasource="mydsname"
externalConnection="true" mode="jta">
<tuscany:xaConnectionProperties
xaDataSouceClass="
com.mysql.jdbc.optional.xyz.MysqlXADataSource">
<tuscany:xaDataSourceConfig>
<tuscany:xaMethod name="setXXX" value="valXXX" />
<tuscany:xaMethod name="setYYY" value="valYYY" />
</tuscany:xaDataSourceConfig>
</tuscany:xaConnectionProperties>
</tuscany:connectionInfo>
</tuscany:implementation.das>
</component>
-----------------------------------------------------------------------------------------------------------------------------
Please give me all comments/feedback to refine the above.
regards,
amita
On 9/14/07, Luciano Resende <lu...@gmail.com> wrote:
>
> Hey, very good, some comments inline
>
> One question that I have is regarding the Transaction Manager, who is
> responsible for creating the transaction manager ? The SCA runtime, or
> implementations ? In the case of SCA runtime, we need to investigate
> that part, but I guess we can start by having it under the
> implementation as a proof of concept for now.
>
> On 9/13/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > Hi,
> > I have given this a try based on what I tried in JIRA-1665 (Sample Using
> > JOTM with DAS)
> > Here also I am using JOTM with SCA+DAS. Currently played with 2 simple
> > intents:
>
> I think we are going to use geronimo transaction manager with SCA
> integration, and there is a sample on implementation.bepel on how to
> use it, it's very simple, could you try using that one ?
>
> > a> transaction (Tx management from External TM), b> noTransaction (Tx
> > management from DAS)
> >
> > The only changes needed are as below:-
> > A> tuscany-data-engine-helper:-
> > 1)DataAccessEngineManager
> > new method getDAS(String config, ConnectionInfo connectionInfo,
> List<Intent>
> > intents, List<PolicySet> policySets)
> > Here if intent "a>transaction" is detected, ConnectionInfo.setManagedTx
> (false)
> > will be called.
> > This modified connnectionInfo will be passed through configHelper to the
> new
> > DAS instance.
> > This way if external TM is going to manage Tx, DAS is signaled for it.
> >
>
> Great... I'll leave comments on the policy side to Venkat or Sebastien
> or others that have been playing on this area...
>
> > And logic to support this method
> >
> > 2) ConnectionInfo
> > new attribute managedtx with setter/getter
> >
>
> Ok
>
> > B> tuscany-implementation-das
> > 1) DASImplementation implements PolicyAttachPoint
> >
> > 2) DASImplementationProcessor
> > read(reader) - will read policies and intents on DASImplementation from
> > .composite
> >
>
> Who should read here, implementation.das or we should delegate to the
> policy artifact processors ?
>
> Ans: it will be done by policy processor
> 3) DASImplementationProvider
> > createInvoker() will call getDAS(passing config, connectioninfo,
> intents,
> > policies)
> > same will be for createCallbackInvoker()
> >
>
> What other information you will need from intents and policies when
> creating DAS ? you already passed the managed transaction flag inside
> the connectionInfo, right ? Note that there is still support for a das
> config file, how are you going to manage that ? We probably need to
> throw an exception if DAS config file sets does NOT set the managed
> transaction flag, but transaction policy is set.
>
> > With these above changes and with setup similar to JIRA-1665 sample, I
> could
> > see
> > that the external connection is being used by DAS (naming service is
> > resolving
> > datasource properly).
> >
> > The point I am stuck at is, in RDB-DAS, when we use external DS, we do
> not
> > pass
> > userName, password. But MYSQL (which with InnoDB supports Txn and works
> well
> > with JOTM) does need id, pwd in ds.getConnection(). This can be case
> with
> > other DBs as well.
> >
> > So, it looks like DAS config.xsd needs to allow passing userName,
> password
> > in ConnectionInfo too ( and not just for ConnectionProperties).
> >
> > Thus below will be the changed DAS config portion:-
> > <xsd:complexType name="ConnectionInfo">
> > <xsd:sequence>
> > <xsd:element maxOccurs="1" minOccurs="0"
> > name="ConnectionProperties" type="config:ConnectionProperties"/>
> > </xsd:sequence>
> > <xsd:attribute name="dataSource" type="xsd:string"/>
> > <xsd:attribute name="managedtx" type="xsd:boolean"
> default="true"/>
> > <xsd:attribute name="userName" type="xsd:string" default=""/>
> > <xsd:attribute name="password" type="xsd:string" default=""/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="ConnectionProperties">
> > <xsd:attribute name="driverClass" type="xsd:string"/>
> > <xsd:attribute name="databaseURL" type="xsd:string"/>
> > <xsd:attribute name="loginTimeout" type="xsd:int"
> > default="0"/>
> > </xsd:complexType>
> >
>
> Create a DAS jira for this, and we can investigate further...
>
> > Suggestion? If this looks OK, I would like to make the above changes and
> > create a sample in tuscany-implementation-das demoing use of intent and
> ext
> > TM.
>
> I have a demo in progress, probably is good to have a test case for
> now, and we could incorporate transaction support on the demo.
>
> > Will give a try with geronimo as well.
>
>
> >
> > Regards,
> > Amita
> >
> > On 9/2/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > >
> > > [snip]
> > > Luciano Resende wrote:
> > > > I guess your suggestion for starting simple is fine, and I guess
> > > > implementation.das could get integrated with SCA Policy and DAS
> would
> > > > have the necessary support, unless we find some bugs on the DAS
> side.
> > > > I'll see if I can get to this in the coming weeks...
> > > >
> > > > BTW, what transaction manager are we going to use in Tuscany ? Do
> we
> > > > have any today ?
> > > >
> > >
> > > Two suggestions:
> > > - in a standalone environment, use JOTM [1]
> > > - in Geronimo, get the TM from Geronimo, as done in the
> Tuscany/Geronimo
> > > plugin at [2]
> > >
> > > [1] http://jotm.objectweb.org/
> > > [2] http://svn.apache.org/repos/asf/geronimo/plugins/tuscany
> > >
> > > --
> > > Jean-Sebastien
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
Re: [DAS] Transaction support - a bigger picture question
Posted by Luciano Resende <lu...@gmail.com>.
Hey, very good, some comments inline
One question that I have is regarding the Transaction Manager, who is
responsible for creating the transaction manager ? The SCA runtime, or
implementations ? In the case of SCA runtime, we need to investigate
that part, but I guess we can start by having it under the
implementation as a proof of concept for now.
On 9/13/07, Amita Vadhavkar <am...@gmail.com> wrote:
> Hi,
> I have given this a try based on what I tried in JIRA-1665 (Sample Using
> JOTM with DAS)
> Here also I am using JOTM with SCA+DAS. Currently played with 2 simple
> intents:
I think we are going to use geronimo transaction manager with SCA
integration, and there is a sample on implementation.bepel on how to
use it, it's very simple, could you try using that one ?
> a> transaction (Tx management from External TM), b> noTransaction (Tx
> management from DAS)
>
> The only changes needed are as below:-
> A> tuscany-data-engine-helper:-
> 1)DataAccessEngineManager
> new method getDAS(String config, ConnectionInfo connectionInfo, List<Intent>
> intents, List<PolicySet> policySets)
> Here if intent "a>transaction" is detected, ConnectionInfo.setManagedTx(false)
> will be called.
> This modified connnectionInfo will be passed through configHelper to the new
> DAS instance.
> This way if external TM is going to manage Tx, DAS is signaled for it.
>
Great... I'll leave comments on the policy side to Venkat or Sebastien
or others that have been playing on this area...
> And logic to support this method
>
> 2) ConnectionInfo
> new attribute managedtx with setter/getter
>
Ok
> B> tuscany-implementation-das
> 1) DASImplementation implements PolicyAttachPoint
>
> 2) DASImplementationProcessor
> read(reader) - will read policies and intents on DASImplementation from
> .composite
>
Who should read here, implementation.das or we should delegate to the
policy artifact processors ?
> 3) DASImplementationProvider
> createInvoker() will call getDAS(passing config, connectioninfo, intents,
> policies)
> same will be for createCallbackInvoker()
>
What other information you will need from intents and policies when
creating DAS ? you already passed the managed transaction flag inside
the connectionInfo, right ? Note that there is still support for a das
config file, how are you going to manage that ? We probably need to
throw an exception if DAS config file sets does NOT set the managed
transaction flag, but transaction policy is set.
> With these above changes and with setup similar to JIRA-1665 sample, I could
> see
> that the external connection is being used by DAS (naming service is
> resolving
> datasource properly).
>
> The point I am stuck at is, in RDB-DAS, when we use external DS, we do not
> pass
> userName, password. But MYSQL (which with InnoDB supports Txn and works well
> with JOTM) does need id, pwd in ds.getConnection(). This can be case with
> other DBs as well.
>
> So, it looks like DAS config.xsd needs to allow passing userName, password
> in ConnectionInfo too ( and not just for ConnectionProperties).
>
> Thus below will be the changed DAS config portion:-
> <xsd:complexType name="ConnectionInfo">
> <xsd:sequence>
> <xsd:element maxOccurs="1" minOccurs="0"
> name="ConnectionProperties" type="config:ConnectionProperties"/>
> </xsd:sequence>
> <xsd:attribute name="dataSource" type="xsd:string"/>
> <xsd:attribute name="managedtx" type="xsd:boolean" default="true"/>
> <xsd:attribute name="userName" type="xsd:string" default=""/>
> <xsd:attribute name="password" type="xsd:string" default=""/>
> </xsd:complexType>
>
> <xsd:complexType name="ConnectionProperties">
> <xsd:attribute name="driverClass" type="xsd:string"/>
> <xsd:attribute name="databaseURL" type="xsd:string"/>
> <xsd:attribute name="loginTimeout" type="xsd:int"
> default="0"/>
> </xsd:complexType>
>
Create a DAS jira for this, and we can investigate further...
> Suggestion? If this looks OK, I would like to make the above changes and
> create a sample in tuscany-implementation-das demoing use of intent and ext
> TM.
I have a demo in progress, probably is good to have a test case for
now, and we could incorporate transaction support on the demo.
> Will give a try with geronimo as well.
>
> Regards,
> Amita
>
> On 9/2/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> > [snip]
> > Luciano Resende wrote:
> > > I guess your suggestion for starting simple is fine, and I guess
> > > implementation.das could get integrated with SCA Policy and DAS would
> > > have the necessary support, unless we find some bugs on the DAS side.
> > > I'll see if I can get to this in the coming weeks...
> > >
> > > BTW, what transaction manager are we going to use in Tuscany ? Do we
> > > have any today ?
> > >
> >
> > Two suggestions:
> > - in a standalone environment, use JOTM [1]
> > - in Geronimo, get the TM from Geronimo, as done in the Tuscany/Geronimo
> > plugin at [2]
> >
> > [1] http://jotm.objectweb.org/
> > [2] http://svn.apache.org/repos/asf/geronimo/plugins/tuscany
> >
> > --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: [DAS] Transaction support - a bigger picture question
Posted by Luciano Resende <lu...@gmail.com>.
Hey, very good, some comments inline
One question that I have is regarding the Transaction Manager, who is
responsible for creating the transaction manager ? The SCA runtime, or
implementations ? In the case of SCA runtime, we need to investigate
that part, but I guess we can start by having it under the
implementation as a proof of concept for now.
On 9/13/07, Amita Vadhavkar <am...@gmail.com> wrote:
> Hi,
> I have given this a try based on what I tried in JIRA-1665 (Sample Using
> JOTM with DAS)
> Here also I am using JOTM with SCA+DAS. Currently played with 2 simple
> intents:
I think we are going to use geronimo transaction manager with SCA
integration, and there is a sample on implementation.bepel on how to
use it, it's very simple, could you try using that one ?
> a> transaction (Tx management from External TM), b> noTransaction (Tx
> management from DAS)
>
> The only changes needed are as below:-
> A> tuscany-data-engine-helper:-
> 1)DataAccessEngineManager
> new method getDAS(String config, ConnectionInfo connectionInfo, List<Intent>
> intents, List<PolicySet> policySets)
> Here if intent "a>transaction" is detected, ConnectionInfo.setManagedTx(false)
> will be called.
> This modified connnectionInfo will be passed through configHelper to the new
> DAS instance.
> This way if external TM is going to manage Tx, DAS is signaled for it.
>
Great... I'll leave comments on the policy side to Venkat or Sebastien
or others that have been playing on this area...
> And logic to support this method
>
> 2) ConnectionInfo
> new attribute managedtx with setter/getter
>
Ok
> B> tuscany-implementation-das
> 1) DASImplementation implements PolicyAttachPoint
>
> 2) DASImplementationProcessor
> read(reader) - will read policies and intents on DASImplementation from
> .composite
>
Who should read here, implementation.das or we should delegate to the
policy artifact processors ?
> 3) DASImplementationProvider
> createInvoker() will call getDAS(passing config, connectioninfo, intents,
> policies)
> same will be for createCallbackInvoker()
>
What other information you will need from intents and policies when
creating DAS ? you already passed the managed transaction flag inside
the connectionInfo, right ? Note that there is still support for a das
config file, how are you going to manage that ? We probably need to
throw an exception if DAS config file sets does NOT set the managed
transaction flag, but transaction policy is set.
> With these above changes and with setup similar to JIRA-1665 sample, I could
> see
> that the external connection is being used by DAS (naming service is
> resolving
> datasource properly).
>
> The point I am stuck at is, in RDB-DAS, when we use external DS, we do not
> pass
> userName, password. But MYSQL (which with InnoDB supports Txn and works well
> with JOTM) does need id, pwd in ds.getConnection(). This can be case with
> other DBs as well.
>
> So, it looks like DAS config.xsd needs to allow passing userName, password
> in ConnectionInfo too ( and not just for ConnectionProperties).
>
> Thus below will be the changed DAS config portion:-
> <xsd:complexType name="ConnectionInfo">
> <xsd:sequence>
> <xsd:element maxOccurs="1" minOccurs="0"
> name="ConnectionProperties" type="config:ConnectionProperties"/>
> </xsd:sequence>
> <xsd:attribute name="dataSource" type="xsd:string"/>
> <xsd:attribute name="managedtx" type="xsd:boolean" default="true"/>
> <xsd:attribute name="userName" type="xsd:string" default=""/>
> <xsd:attribute name="password" type="xsd:string" default=""/>
> </xsd:complexType>
>
> <xsd:complexType name="ConnectionProperties">
> <xsd:attribute name="driverClass" type="xsd:string"/>
> <xsd:attribute name="databaseURL" type="xsd:string"/>
> <xsd:attribute name="loginTimeout" type="xsd:int"
> default="0"/>
> </xsd:complexType>
>
Create a DAS jira for this, and we can investigate further...
> Suggestion? If this looks OK, I would like to make the above changes and
> create a sample in tuscany-implementation-das demoing use of intent and ext
> TM.
I have a demo in progress, probably is good to have a test case for
now, and we could incorporate transaction support on the demo.
> Will give a try with geronimo as well.
>
> Regards,
> Amita
>
> On 9/2/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> > [snip]
> > Luciano Resende wrote:
> > > I guess your suggestion for starting simple is fine, and I guess
> > > implementation.das could get integrated with SCA Policy and DAS would
> > > have the necessary support, unless we find some bugs on the DAS side.
> > > I'll see if I can get to this in the coming weeks...
> > >
> > > BTW, what transaction manager are we going to use in Tuscany ? Do we
> > > have any today ?
> > >
> >
> > Two suggestions:
> > - in a standalone environment, use JOTM [1]
> > - in Geronimo, get the TM from Geronimo, as done in the Tuscany/Geronimo
> > plugin at [2]
> >
> > [1] http://jotm.objectweb.org/
> > [2] http://svn.apache.org/repos/asf/geronimo/plugins/tuscany
> >
> > --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DAS] Transaction support - a bigger picture question
Posted by Amita Vadhavkar <am...@gmail.com>.
Hi,
I have given this a try based on what I tried in JIRA-1665 (Sample Using
JOTM with DAS)
Here also I am using JOTM with SCA+DAS. Currently played with 2 simple
intents:
a> transaction (Tx management from External TM), b> noTransaction (Tx
management from DAS)
The only changes needed are as below:-
A> tuscany-data-engine-helper:-
1)DataAccessEngineManager
new method getDAS(String config, ConnectionInfo connectionInfo, List<Intent>
intents, List<PolicySet> policySets)
Here if intent "a>transaction" is detected, ConnectionInfo.setManagedTx(false)
will be called.
This modified connnectionInfo will be passed through configHelper to the new
DAS instance.
This way if external TM is going to manage Tx, DAS is signaled for it.
And logic to support this method
2) ConnectionInfo
new attribute managedtx with setter/getter
B> tuscany-implementation-das
1) DASImplementation implements PolicyAttachPoint
2) DASImplementationProcessor
read(reader) - will read policies and intents on DASImplementation from
.composite
3) DASImplementationProvider
createInvoker() will call getDAS(passing config, connectioninfo, intents,
policies)
same will be for createCallbackInvoker()
With these above changes and with setup similar to JIRA-1665 sample, I could
see
that the external connection is being used by DAS (naming service is
resolving
datasource properly).
The point I am stuck at is, in RDB-DAS, when we use external DS, we do not
pass
userName, password. But MYSQL (which with InnoDB supports Txn and works well
with JOTM) does need id, pwd in ds.getConnection(). This can be case with
other DBs as well.
So, it looks like DAS config.xsd needs to allow passing userName, password
in ConnectionInfo too ( and not just for ConnectionProperties).
Thus below will be the changed DAS config portion:-
<xsd:complexType name="ConnectionInfo">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0"
name="ConnectionProperties" type="config:ConnectionProperties"/>
</xsd:sequence>
<xsd:attribute name="dataSource" type="xsd:string"/>
<xsd:attribute name="managedtx" type="xsd:boolean" default="true"/>
<xsd:attribute name="userName" type="xsd:string" default=""/>
<xsd:attribute name="password" type="xsd:string" default=""/>
</xsd:complexType>
<xsd:complexType name="ConnectionProperties">
<xsd:attribute name="driverClass" type="xsd:string"/>
<xsd:attribute name="databaseURL" type="xsd:string"/>
<xsd:attribute name="loginTimeout" type="xsd:int"
default="0"/>
</xsd:complexType>
Suggestion? If this looks OK, I would like to make the above changes and
create a sample in tuscany-implementation-das demoing use of intent and ext
TM.
Will give a try with geronimo as well.
Regards,
Amita
On 9/2/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> [snip]
> Luciano Resende wrote:
> > I guess your suggestion for starting simple is fine, and I guess
> > implementation.das could get integrated with SCA Policy and DAS would
> > have the necessary support, unless we find some bugs on the DAS side.
> > I'll see if I can get to this in the coming weeks...
> >
> > BTW, what transaction manager are we going to use in Tuscany ? Do we
> > have any today ?
> >
>
> Two suggestions:
> - in a standalone environment, use JOTM [1]
> - in Geronimo, get the TM from Geronimo, as done in the Tuscany/Geronimo
> plugin at [2]
>
> [1] http://jotm.objectweb.org/
> [2] http://svn.apache.org/repos/asf/geronimo/plugins/tuscany
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [DAS] Transaction support - a bigger picture question
Posted by Amita Vadhavkar <am...@gmail.com>.
Hi,
I have given this a try based on what I tried in JIRA-1665 (Sample Using
JOTM with DAS)
Here also I am using JOTM with SCA+DAS. Currently played with 2 simple
intents:
a> transaction (Tx management from External TM), b> noTransaction (Tx
management from DAS)
The only changes needed are as below:-
A> tuscany-data-engine-helper:-
1)DataAccessEngineManager
new method getDAS(String config, ConnectionInfo connectionInfo, List<Intent>
intents, List<PolicySet> policySets)
Here if intent "a>transaction" is detected, ConnectionInfo.setManagedTx(false)
will be called.
This modified connnectionInfo will be passed through configHelper to the new
DAS instance.
This way if external TM is going to manage Tx, DAS is signaled for it.
And logic to support this method
2) ConnectionInfo
new attribute managedtx with setter/getter
B> tuscany-implementation-das
1) DASImplementation implements PolicyAttachPoint
2) DASImplementationProcessor
read(reader) - will read policies and intents on DASImplementation from
.composite
3) DASImplementationProvider
createInvoker() will call getDAS(passing config, connectioninfo, intents,
policies)
same will be for createCallbackInvoker()
With these above changes and with setup similar to JIRA-1665 sample, I could
see
that the external connection is being used by DAS (naming service is
resolving
datasource properly).
The point I am stuck at is, in RDB-DAS, when we use external DS, we do not
pass
userName, password. But MYSQL (which with InnoDB supports Txn and works well
with JOTM) does need id, pwd in ds.getConnection(). This can be case with
other DBs as well.
So, it looks like DAS config.xsd needs to allow passing userName, password
in ConnectionInfo too ( and not just for ConnectionProperties).
Thus below will be the changed DAS config portion:-
<xsd:complexType name="ConnectionInfo">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0"
name="ConnectionProperties" type="config:ConnectionProperties"/>
</xsd:sequence>
<xsd:attribute name="dataSource" type="xsd:string"/>
<xsd:attribute name="managedtx" type="xsd:boolean" default="true"/>
<xsd:attribute name="userName" type="xsd:string" default=""/>
<xsd:attribute name="password" type="xsd:string" default=""/>
</xsd:complexType>
<xsd:complexType name="ConnectionProperties">
<xsd:attribute name="driverClass" type="xsd:string"/>
<xsd:attribute name="databaseURL" type="xsd:string"/>
<xsd:attribute name="loginTimeout" type="xsd:int"
default="0"/>
</xsd:complexType>
Suggestion? If this looks OK, I would like to make the above changes and
create a sample in tuscany-implementation-das demoing use of intent and ext
TM.
Will give a try with geronimo as well.
Regards,
Amita
On 9/2/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> [snip]
> Luciano Resende wrote:
> > I guess your suggestion for starting simple is fine, and I guess
> > implementation.das could get integrated with SCA Policy and DAS would
> > have the necessary support, unless we find some bugs on the DAS side.
> > I'll see if I can get to this in the coming weeks...
> >
> > BTW, what transaction manager are we going to use in Tuscany ? Do we
> > have any today ?
> >
>
> Two suggestions:
> - in a standalone environment, use JOTM [1]
> - in Geronimo, get the TM from Geronimo, as done in the Tuscany/Geronimo
> plugin at [2]
>
> [1] http://jotm.objectweb.org/
> [2] http://svn.apache.org/repos/asf/geronimo/plugins/tuscany
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [DAS] Transaction support - a bigger picture question
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Luciano Resende wrote:
> I guess your suggestion for starting simple is fine, and I guess
> implementation.das could get integrated with SCA Policy and DAS would
> have the necessary support, unless we find some bugs on the DAS side.
> I'll see if I can get to this in the coming weeks...
>
> BTW, what transaction manager are we going to use in Tuscany ? Do we
> have any today ?
>
Two suggestions:
- in a standalone environment, use JOTM [1]
- in Geronimo, get the TM from Geronimo, as done in the Tuscany/Geronimo
plugin at [2]
[1] http://jotm.objectweb.org/
[2] http://svn.apache.org/repos/asf/geronimo/plugins/tuscany
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: [DAS] Transaction support - a bigger picture question
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Luciano Resende wrote:
> I guess your suggestion for starting simple is fine, and I guess
> implementation.das could get integrated with SCA Policy and DAS would
> have the necessary support, unless we find some bugs on the DAS side.
> I'll see if I can get to this in the coming weeks...
>
> BTW, what transaction manager are we going to use in Tuscany ? Do we
> have any today ?
>
Two suggestions:
- in a standalone environment, use JOTM [1]
- in Geronimo, get the TM from Geronimo, as done in the Tuscany/Geronimo
plugin at [2]
[1] http://jotm.objectweb.org/
[2] http://svn.apache.org/repos/asf/geronimo/plugins/tuscany
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DAS] Transaction support - a bigger picture question
Posted by Luciano Resende <lu...@gmail.com>.
I guess your suggestion for starting simple is fine, and I guess
implementation.das could get integrated with SCA Policy and DAS would
have the necessary support, unless we find some bugs on the DAS side.
I'll see if I can get to this in the coming weeks...
BTW, what transaction manager are we going to use in Tuscany ? Do we
have any today ?
On 8/27/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Comments inline.
>
> [snip]
> Amita Vadhavkar wrote:
> > I have not worked on the latest DAS-SCA integration so far, and am quite
> > sure Lucinao
> > will have good pointers in this area. But looking at the current
> > tuscany-implementation-das, can see the following possible.
>
> Yes, I guess the idea is to:
>
> - access Data inside an SCA component declared with <implementation-das>
>
> - let the application developer annotate the component implementation
> and services with transaction policy intents to indicate what he wants
> in terms of transaction
>
>
> > So take this as my attempt to understand
> > intents/policySets
> > and DAS-SCA integration :)
> >
> > DASImplementation implements org.apache.tuscany.sca.assembly.Implementationand
> > contains org.apache.tuscany.sca.assembly.Service dasService.
> > Using dasService, requiredIntents on the Service can be found.
> >
> >
>
> There are two categories of policy intents in SCA:
>
> - implementation policy intents - used to indicate requirements of the
> component implementation (authorization for example, i.e. you must be
> authorized to execute my implementation)
>
> - interaction policy intents - used to configure how a component will
> interact with others (confidentiality for example, i.e. messages
> exchanged with my component must be encrypted)
>
> I think that the same will have to apply to transactions as well, the
> DAS implementation will probably have to deal with intents specified on
> both services and the implementation itself.
>
> > org.apache.tuscany.das.rdb.DAS interface can be enhanced to accept these
> > intents. DAS
> > internally can configure DASConfig reflecting the intents specified , so
> > that DAS instance
> > construction happens with correct attributes. Based on these attributes DAS
> > transaction control
> > will occur (if intent is TransactionControl).
> >
> > Intent TransactionControl can be qualified as say, 1) Container Transaction
> > Control,
> > 2) DAS Transaction Control.
> >
>
> Can you describe this a bit more to help me understand what you mean by
> Container transaction control vs DAS transaction control?
>
> > Advantage of having intent attached to a service will be, using different
> > intents for different services
> > of same component.
> >
>
> Yes, different services -> different interaction policies
>
> > Questions:
> > What will be the policySets here?
> > Say, if policySet/intent "Container Transaction Control" mandates that the
> > implementation should expose
> > getConnection() so that container Runtime can use it, how this mandate can
> > be achieved?
> >
>
> Not sure at all yet. A PolicySet translates an Intent to the
> corresponding configuration of the underlying runtime, so it really
> depends on what the DAS + SCA runtime will expect.
>
> [snip]
> >> On 8/20/07, Mike Edwards <mi...@gmail.com> wrote:
> >>
> >>> Folks,
> >>>
> >>> Sorry to cut across the discussion about Transaction support in DAS, but
> >>> are folks aware of the proposal for Transaction support in SCA?
> >>>
> >>> ....which leads to the entertaining question of how the DAS transaction
> >>> support relates to the SCA transaction support.
> >>>
> >>> The problem at the moment is that the SCA spec group only has an
> >>> unpublished draft of the Transaction support spec. The intention is to
> >>> publish an updated draft in the near future.
> >>>
> >>> However, I can say that the SCA spec mechanism is based on the use of
> >>> Intents to apply transactional characteristics to SCA components.
> >>>
> >>>
>
> I've seen several exchanges on the list already from people interested
> in some support for transactions... So since the spec is not ready yet,
> how about starting now with something really simple like an
> implementation policy intent that would just say:
> - transaction - i.e. my implementation must run as part of a transaction
> - noTransaction - i.e. I don't want to run as part of a transaction
>
> It may look simplistic, but will help us understand the end to end
> story, work on the necessary plumbing and integration with a transaction
> manager etc. and we can always add more later and adjust the details of
> the intents and policySets when the spec is ready.
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: [DAS] Transaction support - a bigger picture question
Posted by Luciano Resende <lu...@gmail.com>.
I guess your suggestion for starting simple is fine, and I guess
implementation.das could get integrated with SCA Policy and DAS would
have the necessary support, unless we find some bugs on the DAS side.
I'll see if I can get to this in the coming weeks...
BTW, what transaction manager are we going to use in Tuscany ? Do we
have any today ?
On 8/27/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Comments inline.
>
> [snip]
> Amita Vadhavkar wrote:
> > I have not worked on the latest DAS-SCA integration so far, and am quite
> > sure Lucinao
> > will have good pointers in this area. But looking at the current
> > tuscany-implementation-das, can see the following possible.
>
> Yes, I guess the idea is to:
>
> - access Data inside an SCA component declared with <implementation-das>
>
> - let the application developer annotate the component implementation
> and services with transaction policy intents to indicate what he wants
> in terms of transaction
>
>
> > So take this as my attempt to understand
> > intents/policySets
> > and DAS-SCA integration :)
> >
> > DASImplementation implements org.apache.tuscany.sca.assembly.Implementationand
> > contains org.apache.tuscany.sca.assembly.Service dasService.
> > Using dasService, requiredIntents on the Service can be found.
> >
> >
>
> There are two categories of policy intents in SCA:
>
> - implementation policy intents - used to indicate requirements of the
> component implementation (authorization for example, i.e. you must be
> authorized to execute my implementation)
>
> - interaction policy intents - used to configure how a component will
> interact with others (confidentiality for example, i.e. messages
> exchanged with my component must be encrypted)
>
> I think that the same will have to apply to transactions as well, the
> DAS implementation will probably have to deal with intents specified on
> both services and the implementation itself.
>
> > org.apache.tuscany.das.rdb.DAS interface can be enhanced to accept these
> > intents. DAS
> > internally can configure DASConfig reflecting the intents specified , so
> > that DAS instance
> > construction happens with correct attributes. Based on these attributes DAS
> > transaction control
> > will occur (if intent is TransactionControl).
> >
> > Intent TransactionControl can be qualified as say, 1) Container Transaction
> > Control,
> > 2) DAS Transaction Control.
> >
>
> Can you describe this a bit more to help me understand what you mean by
> Container transaction control vs DAS transaction control?
>
> > Advantage of having intent attached to a service will be, using different
> > intents for different services
> > of same component.
> >
>
> Yes, different services -> different interaction policies
>
> > Questions:
> > What will be the policySets here?
> > Say, if policySet/intent "Container Transaction Control" mandates that the
> > implementation should expose
> > getConnection() so that container Runtime can use it, how this mandate can
> > be achieved?
> >
>
> Not sure at all yet. A PolicySet translates an Intent to the
> corresponding configuration of the underlying runtime, so it really
> depends on what the DAS + SCA runtime will expect.
>
> [snip]
> >> On 8/20/07, Mike Edwards <mi...@gmail.com> wrote:
> >>
> >>> Folks,
> >>>
> >>> Sorry to cut across the discussion about Transaction support in DAS, but
> >>> are folks aware of the proposal for Transaction support in SCA?
> >>>
> >>> ....which leads to the entertaining question of how the DAS transaction
> >>> support relates to the SCA transaction support.
> >>>
> >>> The problem at the moment is that the SCA spec group only has an
> >>> unpublished draft of the Transaction support spec. The intention is to
> >>> publish an updated draft in the near future.
> >>>
> >>> However, I can say that the SCA spec mechanism is based on the use of
> >>> Intents to apply transactional characteristics to SCA components.
> >>>
> >>>
>
> I've seen several exchanges on the list already from people interested
> in some support for transactions... So since the spec is not ready yet,
> how about starting now with something really simple like an
> implementation policy intent that would just say:
> - transaction - i.e. my implementation must run as part of a transaction
> - noTransaction - i.e. I don't want to run as part of a transaction
>
> It may look simplistic, but will help us understand the end to end
> story, work on the necessary plumbing and integration with a transaction
> manager etc. and we can always add more later and adjust the details of
> the intents and policySets when the spec is ready.
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DAS] Transaction support - a bigger picture question
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Comments inline.
[snip]
Amita Vadhavkar wrote:
> I have not worked on the latest DAS-SCA integration so far, and am quite
> sure Lucinao
> will have good pointers in this area. But looking at the current
> tuscany-implementation-das, can see the following possible.
Yes, I guess the idea is to:
- access Data inside an SCA component declared with <implementation-das>
- let the application developer annotate the component implementation
and services with transaction policy intents to indicate what he wants
in terms of transaction
> So take this as my attempt to understand
> intents/policySets
> and DAS-SCA integration :)
>
> DASImplementation implements org.apache.tuscany.sca.assembly.Implementationand
> contains org.apache.tuscany.sca.assembly.Service dasService.
> Using dasService, requiredIntents on the Service can be found.
>
>
There are two categories of policy intents in SCA:
- implementation policy intents - used to indicate requirements of the
component implementation (authorization for example, i.e. you must be
authorized to execute my implementation)
- interaction policy intents - used to configure how a component will
interact with others (confidentiality for example, i.e. messages
exchanged with my component must be encrypted)
I think that the same will have to apply to transactions as well, the
DAS implementation will probably have to deal with intents specified on
both services and the implementation itself.
> org.apache.tuscany.das.rdb.DAS interface can be enhanced to accept these
> intents. DAS
> internally can configure DASConfig reflecting the intents specified , so
> that DAS instance
> construction happens with correct attributes. Based on these attributes DAS
> transaction control
> will occur (if intent is TransactionControl).
>
> Intent TransactionControl can be qualified as say, 1) Container Transaction
> Control,
> 2) DAS Transaction Control.
>
Can you describe this a bit more to help me understand what you mean by
Container transaction control vs DAS transaction control?
> Advantage of having intent attached to a service will be, using different
> intents for different services
> of same component.
>
Yes, different services -> different interaction policies
> Questions:
> What will be the policySets here?
> Say, if policySet/intent "Container Transaction Control" mandates that the
> implementation should expose
> getConnection() so that container Runtime can use it, how this mandate can
> be achieved?
>
Not sure at all yet. A PolicySet translates an Intent to the
corresponding configuration of the underlying runtime, so it really
depends on what the DAS + SCA runtime will expect.
[snip]
>> On 8/20/07, Mike Edwards <mi...@gmail.com> wrote:
>>
>>> Folks,
>>>
>>> Sorry to cut across the discussion about Transaction support in DAS, but
>>> are folks aware of the proposal for Transaction support in SCA?
>>>
>>> ....which leads to the entertaining question of how the DAS transaction
>>> support relates to the SCA transaction support.
>>>
>>> The problem at the moment is that the SCA spec group only has an
>>> unpublished draft of the Transaction support spec. The intention is to
>>> publish an updated draft in the near future.
>>>
>>> However, I can say that the SCA spec mechanism is based on the use of
>>> Intents to apply transactional characteristics to SCA components.
>>>
>>>
I've seen several exchanges on the list already from people interested
in some support for transactions... So since the spec is not ready yet,
how about starting now with something really simple like an
implementation policy intent that would just say:
- transaction - i.e. my implementation must run as part of a transaction
- noTransaction - i.e. I don't want to run as part of a transaction
It may look simplistic, but will help us understand the end to end
story, work on the necessary plumbing and integration with a transaction
manager etc. and we can always add more later and adjust the details of
the intents and policySets when the spec is ready.
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: [DAS] Transaction support - a bigger picture question
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Comments inline.
[snip]
Amita Vadhavkar wrote:
> I have not worked on the latest DAS-SCA integration so far, and am quite
> sure Lucinao
> will have good pointers in this area. But looking at the current
> tuscany-implementation-das, can see the following possible.
Yes, I guess the idea is to:
- access Data inside an SCA component declared with <implementation-das>
- let the application developer annotate the component implementation
and services with transaction policy intents to indicate what he wants
in terms of transaction
> So take this as my attempt to understand
> intents/policySets
> and DAS-SCA integration :)
>
> DASImplementation implements org.apache.tuscany.sca.assembly.Implementationand
> contains org.apache.tuscany.sca.assembly.Service dasService.
> Using dasService, requiredIntents on the Service can be found.
>
>
There are two categories of policy intents in SCA:
- implementation policy intents - used to indicate requirements of the
component implementation (authorization for example, i.e. you must be
authorized to execute my implementation)
- interaction policy intents - used to configure how a component will
interact with others (confidentiality for example, i.e. messages
exchanged with my component must be encrypted)
I think that the same will have to apply to transactions as well, the
DAS implementation will probably have to deal with intents specified on
both services and the implementation itself.
> org.apache.tuscany.das.rdb.DAS interface can be enhanced to accept these
> intents. DAS
> internally can configure DASConfig reflecting the intents specified , so
> that DAS instance
> construction happens with correct attributes. Based on these attributes DAS
> transaction control
> will occur (if intent is TransactionControl).
>
> Intent TransactionControl can be qualified as say, 1) Container Transaction
> Control,
> 2) DAS Transaction Control.
>
Can you describe this a bit more to help me understand what you mean by
Container transaction control vs DAS transaction control?
> Advantage of having intent attached to a service will be, using different
> intents for different services
> of same component.
>
Yes, different services -> different interaction policies
> Questions:
> What will be the policySets here?
> Say, if policySet/intent "Container Transaction Control" mandates that the
> implementation should expose
> getConnection() so that container Runtime can use it, how this mandate can
> be achieved?
>
Not sure at all yet. A PolicySet translates an Intent to the
corresponding configuration of the underlying runtime, so it really
depends on what the DAS + SCA runtime will expect.
[snip]
>> On 8/20/07, Mike Edwards <mi...@gmail.com> wrote:
>>
>>> Folks,
>>>
>>> Sorry to cut across the discussion about Transaction support in DAS, but
>>> are folks aware of the proposal for Transaction support in SCA?
>>>
>>> ....which leads to the entertaining question of how the DAS transaction
>>> support relates to the SCA transaction support.
>>>
>>> The problem at the moment is that the SCA spec group only has an
>>> unpublished draft of the Transaction support spec. The intention is to
>>> publish an updated draft in the near future.
>>>
>>> However, I can say that the SCA spec mechanism is based on the use of
>>> Intents to apply transactional characteristics to SCA components.
>>>
>>>
I've seen several exchanges on the list already from people interested
in some support for transactions... So since the spec is not ready yet,
how about starting now with something really simple like an
implementation policy intent that would just say:
- transaction - i.e. my implementation must run as part of a transaction
- noTransaction - i.e. I don't want to run as part of a transaction
It may look simplistic, but will help us understand the end to end
story, work on the necessary plumbing and integration with a transaction
manager etc. and we can always add more later and adjust the details of
the intents and policySets when the spec is ready.
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DAS] Transaction support - a bigger picture question
Posted by Amita Vadhavkar <am...@gmail.com>.
I have not worked on the latest DAS-SCA integration so far, and am quite
sure Lucinao
will have good pointers in this area. But looking at the current
tuscany-implementation-das,
can see the following possible. So take this as my attempt to understand
intents/policySets
and DAS-SCA integration :)
DASImplementation implements org.apache.tuscany.sca.assembly.Implementationand
contains org.apache.tuscany.sca.assembly.Service dasService.
Using dasService, requiredIntents on the Service can be found.
org.apache.tuscany.das.rdb.DAS interface can be enhanced to accept these
intents. DAS
internally can configure DASConfig reflecting the intents specified , so
that DAS instance
construction happens with correct attributes. Based on these attributes DAS
transaction control
will occur (if intent is TransactionControl).
Intent TransactionControl can be qualified as say, 1) Container Transaction
Control,
2) DAS Transaction Control.
Advantage of having intent attached to a service will be, using different
intents for different services
of same component.
Questions:
What will be the policySets here?
Say, if policySet/intent "Container Transaction Control" mandates that the
implementation should expose
getConnection() so that container Runtime can use it, how this mandate can
be achieved?
When DAS is not running as part of SCA runtime, DAS Config will support
required equiavalent attributes
thru DAS Config.
Regards,
Amita
On 8/21/07, haleh mahbod <hm...@gmail.com> wrote:
>
> Aligning the two transaction handling model makes sense specially when
> there
> is support for a generic DAS as an SCA service. There has been some
> discussions on DAS as a service on the mailing list in the past.
>
> On 8/20/07, Mike Edwards <mi...@gmail.com> wrote:
> >
> > Folks,
> >
> > Sorry to cut across the discussion about Transaction support in DAS, but
> > are folks aware of the proposal for Transaction support in SCA?
> >
> > ....which leads to the entertaining question of how the DAS transaction
> > support relates to the SCA transaction support.
> >
> > The problem at the moment is that the SCA spec group only has an
> > unpublished draft of the Transaction support spec. The intention is to
> > publish an updated draft in the near future.
> >
> > However, I can say that the SCA spec mechanism is based on the use of
> > Intents to apply transactional characteristics to SCA components.
> >
> >
> > Yours, Mike.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
>
Re: [DAS] Transaction support - a bigger picture question
Posted by Amita Vadhavkar <am...@gmail.com>.
I have not worked on the latest DAS-SCA integration so far, and am quite
sure Lucinao
will have good pointers in this area. But looking at the current
tuscany-implementation-das,
can see the following possible. So take this as my attempt to understand
intents/policySets
and DAS-SCA integration :)
DASImplementation implements org.apache.tuscany.sca.assembly.Implementationand
contains org.apache.tuscany.sca.assembly.Service dasService.
Using dasService, requiredIntents on the Service can be found.
org.apache.tuscany.das.rdb.DAS interface can be enhanced to accept these
intents. DAS
internally can configure DASConfig reflecting the intents specified , so
that DAS instance
construction happens with correct attributes. Based on these attributes DAS
transaction control
will occur (if intent is TransactionControl).
Intent TransactionControl can be qualified as say, 1) Container Transaction
Control,
2) DAS Transaction Control.
Advantage of having intent attached to a service will be, using different
intents for different services
of same component.
Questions:
What will be the policySets here?
Say, if policySet/intent "Container Transaction Control" mandates that the
implementation should expose
getConnection() so that container Runtime can use it, how this mandate can
be achieved?
When DAS is not running as part of SCA runtime, DAS Config will support
required equiavalent attributes
thru DAS Config.
Regards,
Amita
On 8/21/07, haleh mahbod <hm...@gmail.com> wrote:
>
> Aligning the two transaction handling model makes sense specially when
> there
> is support for a generic DAS as an SCA service. There has been some
> discussions on DAS as a service on the mailing list in the past.
>
> On 8/20/07, Mike Edwards <mi...@gmail.com> wrote:
> >
> > Folks,
> >
> > Sorry to cut across the discussion about Transaction support in DAS, but
> > are folks aware of the proposal for Transaction support in SCA?
> >
> > ....which leads to the entertaining question of how the DAS transaction
> > support relates to the SCA transaction support.
> >
> > The problem at the moment is that the SCA spec group only has an
> > unpublished draft of the Transaction support spec. The intention is to
> > publish an updated draft in the near future.
> >
> > However, I can say that the SCA spec mechanism is based on the use of
> > Intents to apply transactional characteristics to SCA components.
> >
> >
> > Yours, Mike.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
>
Re: [DAS] Transaction support - a bigger picture question
Posted by haleh mahbod <hm...@gmail.com>.
Aligning the two transaction handling model makes sense specially when there
is support for a generic DAS as an SCA service. There has been some
discussions on DAS as a service on the mailing list in the past.
On 8/20/07, Mike Edwards <mi...@gmail.com> wrote:
>
> Folks,
>
> Sorry to cut across the discussion about Transaction support in DAS, but
> are folks aware of the proposal for Transaction support in SCA?
>
> ....which leads to the entertaining question of how the DAS transaction
> support relates to the SCA transaction support.
>
> The problem at the moment is that the SCA spec group only has an
> unpublished draft of the Transaction support spec. The intention is to
> publish an updated draft in the near future.
>
> However, I can say that the SCA spec mechanism is based on the use of
> Intents to apply transactional characteristics to SCA components.
>
>
> Yours, Mike.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
Re: [DAS] Transaction support - a bigger picture question
Posted by Mike Edwards <mi...@gmail.com>.
Folks,
Sorry to cut across the discussion about Transaction support in DAS, but
are folks aware of the proposal for Transaction support in SCA?
....which leads to the entertaining question of how the DAS transaction
support relates to the SCA transaction support.
The problem at the moment is that the SCA spec group only has an
unpublished draft of the Transaction support spec. The intention is to
publish an updated draft in the near future.
However, I can say that the SCA spec mechanism is based on the use of
Intents to apply transactional characteristics to SCA components.
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: [DAS] Transaction support
Posted by Amita Vadhavkar <am...@gmail.com>.
Hi,
I have tried to use JOTM and Tomcat and would like to create a sample web
app in
DAS showing how external transaction manager can control DAS transactions.
I am creating another mail thread for any discussion for this sample + JOTM
issues.
We can demonstrate through this and accompanying wiki - how Txn support in
DAS
for externally managed txns should do.
Regards,
Amita
On 8/17/07, Luciano Resende <lu...@gmail.com> wrote:
>
> 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 <am...@gmail.com> 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 <ad...@apache.org> wrote:
> > >
> > > forwarding last message to dev list...
> > >
> > > On 8/17/07, Adriano Crestani <ad...@apache.org> 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 <am...@gmail.com> 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 < hmahbod@gmail.com > 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 < adrianocrestani@apache.org>
> 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 < amita.vadhavkar@gmail.com>
> wrote:
> > > > > > > >
> > > > > > > > On 8/14/07, Adriano Crestani < adrianocrestani@apache.org>
> > > 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.DASImplclass
> > > 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 < amita.vadhavkar@gmail.com>
> > > 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 < luckbr1975@gmail.com>
> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Comments inline
> > > > > > > > > > >
> > > > > > > > > > > On 8/13/07, Amita Vadhavkar <
> amita.vadhavkar@gmail.com>
> > > > > 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 < luckbr1975@gmail.com >
> > > > > 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 <
> > > amita.vadhavkar@gmail.com>
> > > > > > > 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 <
> > > > > adrianocrestani@apache.org>
> > > > > > > > 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 <
> > > > > amita.vadhavkar@gmail.com>
> > > > > > > > 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 <
> > > > > > amita.vadhavkar@gmail.com>
> > > > > > > > > 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:
> > > > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > > > > > > > For additional commands, e-mail:
> > > > > > > tuscany-dev-help@ws.apache.org
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > 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:
> > > > > tuscany-user-unsubscribe@ws.apache.org
> > > > > > > > > > > For additional commands, e-mail:
> > > > > tuscany-user-help@ws.apache.org
> > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
Re: [DAS] Transaction support
Posted by Luciano Resende <lu...@gmail.com>.
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 <am...@gmail.com> 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 <ad...@apache.org> wrote:
> >
> > forwarding last message to dev list...
> >
> > On 8/17/07, Adriano Crestani <ad...@apache.org> 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 <am...@gmail.com> 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 < hmahbod@gmail.com > 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 < adrianocrestani@apache.org> 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 < amita.vadhavkar@gmail.com> wrote:
> > > > > > >
> > > > > > > On 8/14/07, Adriano Crestani < adrianocrestani@apache.org>
> > 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 < amita.vadhavkar@gmail.com>
> > 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 < luckbr1975@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Comments inline
> > > > > > > > > >
> > > > > > > > > > On 8/13/07, Amita Vadhavkar < amita.vadhavkar@gmail.com>
> > > > 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 < luckbr1975@gmail.com >
> > > > 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 <
> > amita.vadhavkar@gmail.com>
> > > > > > 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 <
> > > > adrianocrestani@apache.org>
> > > > > > > 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 <
> > > > amita.vadhavkar@gmail.com>
> > > > > > > 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 <
> > > > > amita.vadhavkar@gmail.com>
> > > > > > > > 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:
> > > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > > > > > > For additional commands, e-mail:
> > > > > > tuscany-dev-help@ws.apache.org
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > 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:
> > > > tuscany-user-unsubscribe@ws.apache.org
> > > > > > > > > > For additional commands, e-mail:
> > > > tuscany-user-help@ws.apache.org
> > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: [DAS] Transaction support
Posted by Luciano Resende <lu...@gmail.com>.
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 <am...@gmail.com> 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 <ad...@apache.org> wrote:
> >
> > forwarding last message to dev list...
> >
> > On 8/17/07, Adriano Crestani <ad...@apache.org> 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 <am...@gmail.com> 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 < hmahbod@gmail.com > 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 < adrianocrestani@apache.org> 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 < amita.vadhavkar@gmail.com> wrote:
> > > > > > >
> > > > > > > On 8/14/07, Adriano Crestani < adrianocrestani@apache.org>
> > 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 < amita.vadhavkar@gmail.com>
> > 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 < luckbr1975@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Comments inline
> > > > > > > > > >
> > > > > > > > > > On 8/13/07, Amita Vadhavkar < amita.vadhavkar@gmail.com>
> > > > 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 < luckbr1975@gmail.com >
> > > > 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 <
> > amita.vadhavkar@gmail.com>
> > > > > > 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 <
> > > > adrianocrestani@apache.org>
> > > > > > > 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 <
> > > > amita.vadhavkar@gmail.com>
> > > > > > > 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 <
> > > > > amita.vadhavkar@gmail.com>
> > > > > > > > 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:
> > > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > > > > > > For additional commands, e-mail:
> > > > > > tuscany-dev-help@ws.apache.org
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > 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:
> > > > tuscany-user-unsubscribe@ws.apache.org
> > > > > > > > > > For additional commands, e-mail:
> > > > tuscany-user-help@ws.apache.org
> > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DAS] Transaction support
Posted by Amita Vadhavkar <am...@gmail.com>.
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 <ad...@apache.org> wrote:
>
> forwarding last message to dev list...
>
> On 8/17/07, Adriano Crestani <ad...@apache.org> 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 <am...@gmail.com> 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 < hmahbod@gmail.com > 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 < adrianocrestani@apache.org> 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 < amita.vadhavkar@gmail.com> wrote:
> > > > > >
> > > > > > On 8/14/07, Adriano Crestani < adrianocrestani@apache.org>
> 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 < amita.vadhavkar@gmail.com>
> 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 < luckbr1975@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Comments inline
> > > > > > > > >
> > > > > > > > > On 8/13/07, Amita Vadhavkar < amita.vadhavkar@gmail.com>
> > > 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 < luckbr1975@gmail.com >
> > > 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 <
> amita.vadhavkar@gmail.com>
> > > > > 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 <
> > > adrianocrestani@apache.org>
> > > > > > 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 <
> > > amita.vadhavkar@gmail.com>
> > > > > > 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 <
> > > > amita.vadhavkar@gmail.com>
> > > > > > > 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:
> > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > > > > > For additional commands, e-mail:
> > > > > tuscany-dev-help@ws.apache.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > 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:
> > > tuscany-user-unsubscribe@ws.apache.org
> > > > > > > > > For additional commands, e-mail:
> > > tuscany-user-help@ws.apache.org
> > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
>
Re: [DAS] Transaction support
Posted by Amita Vadhavkar <am...@gmail.com>.
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 <ad...@apache.org> wrote:
>
> forwarding last message to dev list...
>
> On 8/17/07, Adriano Crestani <ad...@apache.org> 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 <am...@gmail.com> 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 < hmahbod@gmail.com > 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 < adrianocrestani@apache.org> 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 < amita.vadhavkar@gmail.com> wrote:
> > > > > >
> > > > > > On 8/14/07, Adriano Crestani < adrianocrestani@apache.org>
> 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 < amita.vadhavkar@gmail.com>
> 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 < luckbr1975@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Comments inline
> > > > > > > > >
> > > > > > > > > On 8/13/07, Amita Vadhavkar < amita.vadhavkar@gmail.com>
> > > 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 < luckbr1975@gmail.com >
> > > 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 <
> amita.vadhavkar@gmail.com>
> > > > > 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 <
> > > adrianocrestani@apache.org>
> > > > > > 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 <
> > > amita.vadhavkar@gmail.com>
> > > > > > 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 <
> > > > amita.vadhavkar@gmail.com>
> > > > > > > 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:
> > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > > > > > For additional commands, e-mail:
> > > > > tuscany-dev-help@ws.apache.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > 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:
> > > tuscany-user-unsubscribe@ws.apache.org
> > > > > > > > > For additional commands, e-mail:
> > > tuscany-user-help@ws.apache.org
> > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
>
Re: [DAS] Transaction support
Posted by Adriano Crestani <ad...@apache.org>.
forwarding last message to dev list...
On 8/17/07, Adriano Crestani <ad...@apache.org> 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 <am...@gmail.com> 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 < hmahbod@gmail.com > 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 < adrianocrestani@apache.org> 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 < amita.vadhavkar@gmail.com> wrote:
> > > > >
> > > > > On 8/14/07, Adriano Crestani < adrianocrestani@apache.org> 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 < amita.vadhavkar@gmail.com> 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 < luckbr1975@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Comments inline
> > > > > > > >
> > > > > > > > On 8/13/07, Amita Vadhavkar < amita.vadhavkar@gmail.com>
> > 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 < luckbr1975@gmail.com >
> > 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 < amita.vadhavkar@gmail.com>
> > > > 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 <
> > adrianocrestani@apache.org>
> > > > > 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 <
> > amita.vadhavkar@gmail.com>
> > > > > 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 <
> > > amita.vadhavkar@gmail.com>
> > > > > > 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:
> > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > > > > For additional commands, e-mail:
> > > > tuscany-dev-help@ws.apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > 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:
> > tuscany-user-unsubscribe@ws.apache.org
> > > > > > > > For additional commands, e-mail:
> > tuscany-user-help@ws.apache.org
> > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
Re: [DAS] Transaction support
Posted by Adriano Crestani <ad...@apache.org>.
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 <am...@gmail.com> 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 <hmahbod@gmail.com > 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 < adrianocrestani@apache.org> 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 < amita.vadhavkar@gmail.com> wrote:
> > > >
> > > > On 8/14/07, Adriano Crestani <ad...@apache.org> 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 < amita.vadhavkar@gmail.com> 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 < luckbr1975@gmail.com> wrote:
> > > > > > >
> > > > > > > Comments inline
> > > > > > >
> > > > > > > On 8/13/07, Amita Vadhavkar < amita.vadhavkar@gmail.com>
> 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 < luckbr1975@gmail.com > 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 < amita.vadhavkar@gmail.com>
> > > 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 <
> adrianocrestani@apache.org>
> > > > 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 <
> amita.vadhavkar@gmail.com>
> > > > 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 <
> > amita.vadhavkar@gmail.com>
> > > > > 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://lresende.blogspot.com/
> > > > > > > > >
> > > > > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail:
> > tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > > > For additional commands, e-mail:
> > > tuscany-dev-help@ws.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > 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://lresende.blogspot.com/
> > > > > > >
> > > > > > >
> > > >
> ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > > > > For additional commands, e-mail:
> tuscany-user-help@ws.apache.org
> >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DAS] Transaction support
Posted by Amita Vadhavkar <am...@gmail.com>.
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 <hmahbod@gmail.com > 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 < adrianocrestani@apache.org> 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 < amita.vadhavkar@gmail.com> wrote:
> > >
> > > On 8/14/07, Adriano Crestani <ad...@apache.org> 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 < amita.vadhavkar@gmail.com> 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 < luckbr1975@gmail.com> wrote:
> > > > > >
> > > > > > Comments inline
> > > > > >
> > > > > > On 8/13/07, Amita Vadhavkar < amita.vadhavkar@gmail.com> 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 < luckbr1975@gmail.com > 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 < amita.vadhavkar@gmail.com>
> > 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 < adrianocrestani@apache.org>
> > > 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 < amita.vadhavkar@gmail.com>
> > > 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 <
> amita.vadhavkar@gmail.com>
> > > > 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://lresende.blogspot.com/
> > > > > > > >
> > > > > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail:
> tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > > For additional commands, e-mail:
> > tuscany-dev-help@ws.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 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://lresende.blogspot.com/
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DAS] Transaction support
Posted by Amita Vadhavkar <am...@gmail.com>.
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 <hmahbod@gmail.com > 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 < adrianocrestani@apache.org> 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 < amita.vadhavkar@gmail.com> wrote:
> > >
> > > On 8/14/07, Adriano Crestani <ad...@apache.org> 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 < amita.vadhavkar@gmail.com> 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 < luckbr1975@gmail.com> wrote:
> > > > > >
> > > > > > Comments inline
> > > > > >
> > > > > > On 8/13/07, Amita Vadhavkar < amita.vadhavkar@gmail.com> 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 < luckbr1975@gmail.com > 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 < amita.vadhavkar@gmail.com>
> > 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 < adrianocrestani@apache.org>
> > > 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 < amita.vadhavkar@gmail.com>
> > > 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 <
> amita.vadhavkar@gmail.com>
> > > > 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://lresende.blogspot.com/
> > > > > > > >
> > > > > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail:
> tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > > For additional commands, e-mail:
> > tuscany-dev-help@ws.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 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://lresende.blogspot.com/
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DAS] Transaction support
Posted by haleh mahbod <hm...@gmail.com>.
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 <ad...@apache.org> 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 <am...@gmail.com> wrote:
> >
> > On 8/14/07, Adriano Crestani <ad...@apache.org> 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 < amita.vadhavkar@gmail.com> 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 <lu...@gmail.com> wrote:
> > > > >
> > > > > Comments inline
> > > > >
> > > > > On 8/13/07, Amita Vadhavkar < amita.vadhavkar@gmail.com> 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 < luckbr1975@gmail.com > 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 < amita.vadhavkar@gmail.com>
> 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 <ad...@apache.org>
> > 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 <am...@gmail.com>
> > 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 < amita.vadhavkar@gmail.com>
> > > 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > For additional commands, e-mail:
> tuscany-dev-help@ws.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 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: tuscany-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DAS] Transaction support
Posted by haleh mahbod <hm...@gmail.com>.
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 <ad...@apache.org> 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 <am...@gmail.com> wrote:
> >
> > On 8/14/07, Adriano Crestani <ad...@apache.org> 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 < amita.vadhavkar@gmail.com> 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 <lu...@gmail.com> wrote:
> > > > >
> > > > > Comments inline
> > > > >
> > > > > On 8/13/07, Amita Vadhavkar < amita.vadhavkar@gmail.com> 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 < luckbr1975@gmail.com > 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 < amita.vadhavkar@gmail.com>
> 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 <ad...@apache.org>
> > 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 <am...@gmail.com>
> > 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 < amita.vadhavkar@gmail.com>
> > > 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > For additional commands, e-mail:
> tuscany-dev-help@ws.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 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: tuscany-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DAS] Transaction support
Posted by Adriano Crestani <ad...@apache.org>.
------->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 <am...@gmail.com> wrote:
>
> On 8/14/07, Adriano Crestani <ad...@apache.org> 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 < amita.vadhavkar@gmail.com> 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 <lu...@gmail.com> wrote:
> > > >
> > > > Comments inline
> > > >
> > > > On 8/13/07, Amita Vadhavkar < amita.vadhavkar@gmail.com> 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 < luckbr1975@gmail.com > 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 < amita.vadhavkar@gmail.com> 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 <ad...@apache.org>
> 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 <am...@gmail.com>
> 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 < amita.vadhavkar@gmail.com>
> > 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > 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: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > > >
> > >
> >
>
Re: [DAS] Transaction support
Posted by Adriano Crestani <ad...@apache.org>.
------->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 <am...@gmail.com> wrote:
>
> On 8/14/07, Adriano Crestani <ad...@apache.org> 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 < amita.vadhavkar@gmail.com> 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 <lu...@gmail.com> wrote:
> > > >
> > > > Comments inline
> > > >
> > > > On 8/13/07, Amita Vadhavkar < amita.vadhavkar@gmail.com> 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 < luckbr1975@gmail.com > 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 < amita.vadhavkar@gmail.com> 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 <ad...@apache.org>
> 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 <am...@gmail.com>
> 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 < amita.vadhavkar@gmail.com>
> > 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > 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: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > > >
> > >
> >
>
Re: [DAS] Transaction support
Posted by Amita Vadhavkar <am...@gmail.com>.
On 8/14/07, Adriano Crestani <ad...@apache.org> 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 < amita.vadhavkar@gmail.com> 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 <lu...@gmail.com> wrote:
> > >
> > > Comments inline
> > >
> > > On 8/13/07, Amita Vadhavkar < amita.vadhavkar@gmail.com> 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 < luckbr1975@gmail.com > 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 < amita.vadhavkar@gmail.com> 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 <ad...@apache.org> 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 <am...@gmail.com> 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 < amita.vadhavkar@gmail.com>
> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > 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: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> >
>
Re: [DAS] Transaction support
Posted by Amita Vadhavkar <am...@gmail.com>.
On 8/14/07, Adriano Crestani <ad...@apache.org> 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 < amita.vadhavkar@gmail.com> 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 <lu...@gmail.com> wrote:
> > >
> > > Comments inline
> > >
> > > On 8/13/07, Amita Vadhavkar < amita.vadhavkar@gmail.com> 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 < luckbr1975@gmail.com > 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 < amita.vadhavkar@gmail.com> 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 <ad...@apache.org> 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 <am...@gmail.com> 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 < amita.vadhavkar@gmail.com>
> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > 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: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> >
>
Re: [DAS] Transaction support
Posted by Adriano Crestani <ad...@apache.org>.
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.
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?
Regards,
Adriano Crestani
On 8/14/07, Amita Vadhavkar <am...@gmail.com> 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 <lu...@gmail.com> wrote:
> >
> > Comments inline
> >
> > On 8/13/07, Amita Vadhavkar < amita.vadhavkar@gmail.com> 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 <luckbr1975@gmail.com > 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 < amita.vadhavkar@gmail.com> 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 <ad...@apache.org> 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 <am...@gmail.com> 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 <am...@gmail.com> 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://lresende.blogspot.com/
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > Luciano Resende
> > Apache Tuscany Committer
> > http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
> > http://lresende.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
>
Re: [DAS] Transaction support
Posted by Amita Vadhavkar <am...@gmail.com>.
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 <lu...@gmail.com> wrote:
>
> Comments inline
>
> On 8/13/07, Amita Vadhavkar <am...@gmail.com> 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 <lu...@gmail.com> 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 <am...@gmail.com> 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 <ad...@apache.org> 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 <am...@gmail.com> 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 <am...@gmail.com> 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://lresende.blogspot.com/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
Re: [DAS] Transaction support
Posted by Amita Vadhavkar <am...@gmail.com>.
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 <lu...@gmail.com> wrote:
>
> Comments inline
>
> On 8/13/07, Amita Vadhavkar <am...@gmail.com> 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 <lu...@gmail.com> 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 <am...@gmail.com> 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 <ad...@apache.org> 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 <am...@gmail.com> 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 <am...@gmail.com> 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://lresende.blogspot.com/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
Re: [DAS] Transaction support
Posted by Luciano Resende <lu...@gmail.com>.
Comments inline
On 8/13/07, Amita Vadhavkar <am...@gmail.com> 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 <lu...@gmail.com> 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 <am...@gmail.com> 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 <ad...@apache.org> 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 <am...@gmail.com> 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 <am...@gmail.com> 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://lresende.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: [DAS] Transaction support
Posted by Luciano Resende <lu...@gmail.com>.
Comments inline
On 8/13/07, Amita Vadhavkar <am...@gmail.com> 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 <lu...@gmail.com> 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 <am...@gmail.com> 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 <ad...@apache.org> 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 <am...@gmail.com> 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 <am...@gmail.com> 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://lresende.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DAS] Transaction support
Posted by Amita Vadhavkar <am...@gmail.com>.
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
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)
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?
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 <lu...@gmail.com> 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 <am...@gmail.com> 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 <ad...@apache.org> 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 <am...@gmail.com> 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 <am...@gmail.com> 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://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [DAS] Transaction support
Posted by Amita Vadhavkar <am...@gmail.com>.
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
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)
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?
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 <lu...@gmail.com> 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 <am...@gmail.com> 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 <ad...@apache.org> 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 <am...@gmail.com> 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 <am...@gmail.com> 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://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [DAS] Transaction support
Posted by Luciano Resende <lu...@gmail.com>.
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 <am...@gmail.com> 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 <ad...@apache.org> 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 <am...@gmail.com> 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 <am...@gmail.com> 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://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: [DAS] Transaction support
Posted by Luciano Resende <lu...@gmail.com>.
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 <am...@gmail.com> 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 <ad...@apache.org> 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 <am...@gmail.com> 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 <am...@gmail.com> 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://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DAS] Transaction support
Posted by Amita Vadhavkar <am...@gmail.com>.
-----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 <ad...@apache.org> 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 <am...@gmail.com> 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 <am...@gmail.com> 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
> > >
> >
>
Re: [DAS] Transaction support
Posted by Amita Vadhavkar <am...@gmail.com>.
-----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 <ad...@apache.org> 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 <am...@gmail.com> 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 <am...@gmail.com> 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
> > >
> >
>
Re: [DAS] Transaction support
Posted by Adriano Crestani <ad...@apache.org>.
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 <am...@gmail.com> 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 <am...@gmail.com> 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
> >
>