Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.misc -> Re: Checking for uncommited transactions
FC wrote:
> "Billy Verreynne" <vslabs_at_onwe.co.za> wrote in message
> news:b475qk$k8t$1_at_ctb-nnrp2.saix.net...
>
>
>>Or am I missing your point totally? >>
It is still unclear to us what you really are trying to save. If your user hits the UNDO button, you issue a rollback and ORACLE cleans up.
Lets see, here was your original post:
> 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?
And your second post said:
>
> 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?
Let me see if I can rephrase this.
You want to avoid having a "data changed" flag on the client application. Instead you want to check if there are any pending changes in the DB. Presumably these are from invoking one or more of your stored procedures. Specifically you think you will get your answer by querying the locks. And then with the information you can perform a "quick UNDO". I guess this means WHAT exactly, since "performance is not an issue".
My thoughts are that checking the locks seems like the long way around. When
the UNDO button is clicked, doesn't the client just have to:
issue a ROLLBACK
fetch the current records again
?
Okay the rollback may close cursors, so you have to reopen them and start from there. I still do not see why you have any interest in checking locks.
Ed "puzzled" Prochak
-- Ed Prochak running: http://www.faqs.org/faqs/running-faq/ family: http://web.magicinterface.com/~collins -- "Two roads diverged in a wood and I I took the one less travelled by and that has made all the difference." robert frostReceived on Thu Mar 06 2003 - 15:07:05 CST