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 > > >
