Just looked more at the code and found something more interesting - :)
When there is no connectionInfo in DAS Config, managedtx defaults to true,
so when
connection is passed by user (as in TransactionTests), managedtx is true.
So, with the current code case 4) can not occur (which is actually useful)
4)false from caller DAS does not issue commit/rollback,
external caller manages
TransactionTests - if you look closely, there is just "one"
DAS.applyChanges(root)
command
which has 2 INSERT statements using same PK. So, 2nd INSERT gives JDBC
Exception
and DAS uses it to issue rollback. So, TransactionTests is succedding in
getting exception
and avoiding "both" INSERTs due to the fact that "both INSERTs are under
same applyChanges() Command."
What will happen in case when there is a client code like
das.applyChanges(root1);
das.applyChanges(root2);
and the client wants both applyChanges() to be part of the same transaction?
Is it possible with current DAS?
Based on the current code, there will be autocommits for each
applyChanges() which may
not be desirable. Or is DAS forcing clients to grab all changes somehow in
one call
to das.applyChanges() to ensure transactional integrity? Is this
convenient?
___________________________________________________________________________
I could not understand the below statement - please elaborate.
["In the case where client code requires access to the connection, is
there any issue with supplying it to DAS ?'}
___________________________________________________________________________
Regards,
Amita
On 8/14/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> Comments inline
>
> On 8/13/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> > Below is what is happening today:-
> > managedtx(default-true) - config attribute in <ConnectionInfo> element
> to
> > control transactions
> >
> > managedtx database conn. supplied effect on transaction
> >
> ----------------------------------------------------------------------------------------------------------
> > 1)true from caller each DAS command undergoes
> > commit/rollback
> > 2)false from within DAS this is not handled in any way
> > 3)true from within DAS each DAS command undergoes
> > commit/rollback
> > 4)false from caller DAS does not issue
> > commit/rollback, external caller manages
> >
> > So what is lacking is
> > a> ability to issue commit/rollback on group of commands where
> connection is
> > managed by DAS (managedtx=true).(case 3)). this will be essential to
> handle
> > any business unit work. otherwise DAS is ending up today in mimicking
> > autocommit behavior of Database which is not so useful when business
> > transactions need to handle a group of operations as one atomic unit
>
> So, the test case below is an example of multiple commands under one
> transaction. On this scenario, connection is supplied by client, and I
> think this gives you the same results as if the connection was created
> by DAS and exposed to client code, and also gives more flexibility to
> how the client will aquire the connection, or re-use some other
> connection to be part of the same transaction.
>
> [1]
> https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test/TransactionTests.java
>
>
> > b> what is the reason behind providing case 1)? when client/container
> > provides connection, it can be controlled by client/container. and even
> if
> > DAS tries to controll it, as user has handle to connection,
> > commits/rollbacks can be issued by client "async" with what DAS is
> trying to
> > control. So there will be no meaning in DAS controlling the connection
> > supplied by client. And so there is no meaning to managedtx either.
> >
> > c> case 2), as of today there is no way to expose connection to client
> when
> > it is created by DAS. so neither DAS nor client manages transaction. For
> > this case exposing connection thru getConnection() will be useful (for
> other
> > cases, it can be banned)
> >
>
> In the case where client code requires access to the connection, is
> there any issue with supplying it to DAS ?
>
>
> > d> as DAS is "heterogeneous" API, is the DAS config going to be
> > heterogeneous too? If yes, then it will be advantageousto support the
> > transactional nature of RDB using such semantics. If the backend (non
> RDB)
> > does not support transaction, this semantics will be of no use, but
> > in this case the DAS config can be different (more tuned to that
> particular
> > backend)
> > So, it all depends on whether we are following the path to support DAS
> with
> > heterogeneous APIs or not. Will you please elaborate meaning of
> > "heterogeneous API" in context of different flavors of DAS?
> >
>
> Yes, the idea is that each impl would define it's own model,
> inheriting from a common root class (xsd element)
>
> > e> {If you already defined the transaction demarcation flags...}Where
> are we
> > doing that at present? What is there is only issue commit/rollback at
> the
> > end of each DAS Command. Am I missing some other transaction demarcation
> > mechanism already available in DAS?
> >
> > Regards,
> > Amita
> >
> > On 8/13/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> > >
> > > I think that the main goal of DAS, is to be an heterogeneous API that
> > > could be used to implement support for various backends (rdb, ldap,
> > > xml etc). Starting to add various semantics that might be specific to
> > > RDB might take us out of this direction.
> > >
> > > So, for this issue, let's take a step back and think around the
> > > scenarios where this new enhancement might be useful, could you please
> > > list a couple here ? It would be great if you could also mention the
> > > deficiencies you found from managedtx parameter on each scenario.
> > >
> > > Also, couple questions :
> > > - Could you please elaborate more on why you need to expose
> > > DAS.getConnection() ?
> > >
> > > - If you already defined the transaction demarcation flags, why you
> > > still ask the client code to handle start/endTransaction? Why is that
> > > different from passing managedtx = false ?
> > >
> > > On 8/13/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> > > > -----When connection is provider by caller(say container), there is
> no
> > > > meaning
> > > > of managedtx attribute, and it is better to let the caller handle
> the
> > > > transactionality of the operations. So, when DAS is instantiated
> using
> > > > external connection - mandate managedtx = false. Also, expose
> > > > getConnection() from DAS to give a ref. of the connection (User
> already
> > > owns
> > > > it, DAS is just providing ref.). DAS will not issue any
> commit/rollback
> > > >
> > > > -----When connection is created internally, managedtx has a meaning.
> > > > 1>When false, DAS.getConnection() should be exposed and user should
> be
> > > > allowed to handle transactions. DAS should not issue any
> > > commits/rollbacks
> > > >
> > > > 2>When true, do not expose DAS.getConnection().
> > > >
> > > > If TRANSACTION_DEMARCATION_PER_COMMAND is true, work like today
> (commit
> > > > /rollback per command).
> > > >
> > > > If TRANSACTION_DEMARCATION_PER_COMMAND is false (now is time for DAS
> to
> > > > manager group of commands as a sigle transaction).Here, DAS at the
> > > simplest
> > > > can use a static FLAG set/unset using methods
> > > > - void DAS.startTransaction(), //mark FLAG to set
> > > > - void DAS.endTransaction("commit/rollback"). //mark FLAG to reset
> > > > endTransaction() will issue commit/rollback based on arg passed to
> it.
> > > > For any exception condition DAS will issue rollback() on transaction
> and
> > > > will reset the FLAG.
> > > > Client needs to call start/endTransaction() for group of Commands.
> > > >
> > > > Also, here for timeout impelmentation, Java Timer can be used.
> > > >
> > > > Regards,
> > > > Amita
> > > >
> > > > On 8/10/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Hi Amita,
> > > > >
> > > > > I think it can be useful to bunch commands, but I didn't get how
> you
> > > are
> > > > > planning to do it : (
> > > > >
> > > > > What would be the parameter of method getTransaction?
> > > > >
> > > > > Regards,
> > > > > Adriano Crestani
> > > > >
> > > > > On 7/12/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Below is a simple matrix based on current RDB DAS Config,
> showing
> > > what
> > > > > it
> > > > > > does/does not
> > > > > > do today
> > > > > >
> > > > > > managedtx(default-true) - config attribute in <ConnectionInfo>
> > > element
> > > > > to
> > > > > > control transactions
> > > > > >
> > > > > > managedtx database conn. supplied effect on
> transaction
> > > > > >
> > > > > >
> > > > >
> > >
> ----------------------------------------------------------------------------------------------------------
> > > > > > 1)true from caller each
> DAS
> > > > > command
> > > > > > undergoes commit/rollback
> > > > > > 2)false from within DAS this is not
> > > handled
> > > > > > in
> > > > > > any way
> > > > > > 3)true from within DAS each DAS
> > > command
> > > > > > undergoes commit/rollback
> > > > > > 4)false from caller DAS does not
> > > issue
> > > > > > commit/rollback, external caller manages
> > > > > >
> > > > > > Case 2) - when database Connection is created in RDB DAS, it
> does
> > > not
> > > > > > expose
> > > > > > it to caller
> > > > > > today. So, in case 2) neither RDB DAS nor caller can manage
> > > > > > transactions.
> > > > > >
> > > > > > From above, it seems that, RDB DAS in general does not provide
> > > support
> > > > > to
> > > > > > handle a group
> > > > > > of Commands under one database transactions. Only case 4) is the
> > > place
> > > > > > when
> > > > > > multiple
> > > > > > DAS Commands can undergo as one transaction.
> > > > > >
> > > > > > To help serve the transaction control better, I would like to
> > > propose
> > > > > the
> > > > > > following requirements:-
> > > > > > [1]RDB DAS should have a way to issue commit/rollback for
> > > single/group
> > > > > of
> > > > > > Commands
> > > > > > [2]When there is exception, the ongoing transaction should be
> > > > > immediately
> > > > > > aborted by RDB
> > > > > > DAS irrespective of whether it was for single/group of
> Commands
> > > > > > [3]Optional Timeout feature - to have an escape route to end the
> > > > > > transaction controlled by
> > > > > > RDB DAS, when it seems to linger for time > Timeout (to take
> care
> > > of
> > > > > > situations like
> > > > > > deadlocks).
> > > > > >
> > > > > > For this, I am thinking of introducing 2 new attributes in
> RDB
> > > DAS
> > > > > > Config
> > > > > > A) TRANSACTION_DEMARCATION_PER_COMMAND - true/false
> (mandatory
> > > when
> > > > > > managedtx=true)
> > > > > > B) TRANSACTION_TIMEOUT - millis (always optional)
> > > > > > These 2 attributes can be specified at <Config> level.
> > > > > >
> > > > > > When case 1) or 3) - both these attributes will take effect.
> When 2)
> > > or
> > > > > > 4),
> > > > > > these will be
> > > > > > ignored.
> > > > > >
> > > > > > To handle case 2) - here user is required to be given handle to
> the
> > > > > > database
> > > > > > Connection,
> > > > > > created by RDB DAS (in 1) and 3), this should be prohibited, and
> in
> > > 4)
> > > > > > user
> > > > > > already has
> > > > > > handle of the Connection.) This way, the responsibility of
> > > transaction
> > > > > > management can be
> > > > > > taken by user for 4)(as it is today) and 2)(as now user will get
> > > handle)
> > > > > >
> > > > > > For 1) and 3) - TRANSACTION_DEMARCATION_PER_COMMAND=true is
> already
> > > > > > working
> > > > > > in
> > > > > > RDB DAS today. For handling
> > > TRANSACTION_DEMARCATION_PER_COMMAND=false,
> > > > > > new APIs can be given to user like DAS.getTransaction().commit()
> > > > > > /rollback() , so in a
> > > > > > controlled way, user will be able to bunch group of Commands
> based
> > > on
> > > > > > business logic
> > > > > > and issue commits/rollbacks. Also, internally, RDB DAS will be
> > > > > responsible
> > > > > > to rollback in
> > > > > > case of exceptions and in case of Timeouts.
> > > > > >
> > > > > > Please share your thoughts.
> > > > > >
> > > > > > Regards,
> > > > > > Amita
> > > > > >
> > > > > > On 6/12/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > Hi All,
> > > > > > > I just want to clarify if the below is something missing in
> DAS or
> > > > > just
> > > > > > > that I have not understood it clearly.
> > > > > > > Appreciate your response.
> > > > > > >
> > > > > > >
> > > > > > > At present, DAS has managedtx attribute at ConnectionInfo
> > > > > level(default
> > > > > > > true). So when true
> > > > > > > or not specificed, each Command does a database commit.
> When
> > > false,
> > > > > > > external caller is responsible
> > > > > > > for managing transaction.
> > > > > > > There is no way to bunch a set of Commands in one
> transaction
> > > under
> > > > > > > control of DAS, it is at the mercy of
> > > > > > > external caller (when managedtx is false). Is it not useful
> to
> > > > > > > introduce this in DAS, wherein,
> > > > > > > when DAS manages transaction, it can have today's behavior
> > > (similar
> > > > > > to
> > > > > > > autocommit)
> > > > > > > or can have a public API which allows client to commit
> using
> > > the
> > > > > > > connection associated
> > > > > > > with current DAS instance. This way, when the connection is
> not
> > > > > > passed
> > > > > > > from client (but created in DAS,
> > > > > > > using ConnectionInfo and thus not exposed to client),
> client
> > > will
> > > > > > have
> > > > > > > a way to support real transaction
> > > > > > > (multiple logical bunch of Commands) using DAS?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Amita
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Luciano Resende
> > > Apache Tuscany Committer
> > > http://people.apache.org/~lresende
> > > http://lresende.blogspot.com/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
