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
