Re: Checking for uncommited transactions

Sybrand Bakker wrote:

> > 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.
> >
>
> PMON will roll back the transaction!!!!!!!!!!!!!!

When you perform an insert and leave out the commit why and when should PMON rollback the transaction?

PMON will roll back the transaction if you kill the client app. As long as long as the client app lives (e.g. performs a long operation) no transaction will be roll backed.

> > 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.
> >
> Question: where does the pl/sql code run?
> Answer: in the USER's!!!!! session.
> So what does this change????

You are right, simple putting code in pl/sql doesn't change anything. The programmer is in charge to do this. But he is able to do this if all transaction code is in one code block. He may fail, when the transaction code is split in two pl/sql (sql) blocks, called in two different c++ functions from the client app.

> > In simple words: Don't give the end-user the control over
> > transactions.
>
> That is the most stupid assertion I ever saw in this group.
> It is also NOT possible, NEVER!!!!!!

I assume you missunderstood me. I speak about the *end*-user. Of course, transaction control lays in the hand of oracle users.

But it's possible to have an app with a button 'insert user_setting' and a button 'commit'. In this scenario the end-user has the transaction control and is able to lock the table USERS for delete operations.

-- 
Immo Landwerth - XP Pro - D5 Pro SP1 - XanaNews 1.14.1.1