Re: Checking for uncommited transactions

On 11 Mar 2003, mail_ignored_at_web.de wrote:

> Session 1:
>
> Insert a row to user settings (5, 2, 'FROM TWO').
>
> Do not commit.
>
> Session 2:
>
> Try to delete user (3, 'THREE'). This user doesn't have any settings
> therefore this row should deleted immediately - it doesn't.
>
> Session 2 will wait until session 2 performs a commit/rollback.

Yes, I misunderstood your previous statement. But, how does keeping transactions on the server solve anything (You said "Transactions should allways be started and commited on the server EXPLICTLY")? Bad transaction habits can happen on server side just as well.

I take a different route. I don't want any transactions within any application PL/SQL code (unless we are talking batch processes). This would mean that some other database or application process could call that code and have a commit happen without them meaning to. A transaction is a business defined unit of work. Let the business logic define the transaction's boundaries. If there is an error in the business code so that transactions are left open, then fix that. Don't jump to the conclusion that all transactions are server-side.

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