Re: Checking for uncommited transactions

FC wrote:

> Hello Oraclers,
> I was asking myself what are the possible drawbacks of the following
> approach:
>
> I've some client front-ends modifying data by means of stored procedures and
> they are allowed to change several values on different tables before
> committing or rolling back.
> Instead of maintaining a flag indicating whether something has changed on
> the client, I was wondering about the possibility of evaluating a function
> or alike that checks for any pending locks (via V$LOCKED_OBJECT presumably)
> against its session id.
>
> Any thoughts about this?
>
> Bye,
> Flavio

Forget checking locks. It is a complete waste of time. Selects don't lock. And pessimistic locking, in Oracle, is almost always a mistake.

But I don't understand why you would care. Unless you have transaction volume/performance problems ... just update with whatever is submitted.

Alternatively you could run another select and do a field-by-field comparison. This might make sense, in particular, if there is the possibility of another user having changed the record from that which was originally selected.

Daniel Morgan Received on Wed Mar 05 2003 - 14:41:22 CST