Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.misc -> Re: Checking for uncommited transactions
"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