Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: Checking for uncommited transactions

Re: Checking for uncommited transactions

From: FC <flavio_at_tin.it>
Date: Thu, 06 Mar 2003 08:45:57 GMT
Message-ID: <9VD9a.12131$pG1.319720@news1.tin.it>

"DA Morgan" <damorgan_at_exesolutions.com> wrote in message news:3E6660F2.52C33A0B_at_exesolutions.com...

> 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.
>

Well, each user is updating his own stuff, so this is one of those lucky situations where I am 100% sure there are no concurrent changes to the same record.
Volumes of data are very low, so performance is not an issue, I just want to give a quick "undo" possibility to the user without having to check table by table and record by record what he has changed. If I don't allow rollbacks at the db level, then I must write my own rollback at the client level, which violates the first law of the good programmer: do not reinvent the wheel.
So, in the end, since I do not need to check for selects of other users, is there any other strong objection for not querying v$locked_object?

Bye,
Flavio Received on Thu Mar 06 2003 - 02:45:57 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US