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]
