Re: Checking for uncommited transactions

On 12 Mar 2003, mail_ignored_at_web.de wrote:

> What I meant is that transactions should not be commited/rollbacked
> from the client app.

What you are saying is that business users shouldn't define the business transactions.

> Look at our scenario. Let's assume the client will crash/hang after
> the insert or the user leaves his workstation. In this case _no_ user
> is able to delete a record in USERS.
>
> To avoid this problem (in most cases) all transactions should be
> encaspulated in pl/sql code. After the excecution no transactions
> should be open anymore.

No, what you should do is wait until the client has hit a submit button and then do all of the DML and commit, as one single unit.

Your problem is that you allow client's modifications to take place over a long time span (ie, allowing for think time during the transaction). You need to keep all of the modifications in the app until the modifications that define the transaction are ready to be submitted. Until that time, no database modifications should be made.

> In simple words: Don't give the end-user the control over
> transactions.

Completely untrue. A transaction is a business rule. A business user is one who enacts this rule. The application gives them the facility to enact the rule.

-- 
Galen deForest Boyer
Sweet dreams and flying machines in pieces on the ground.