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: Ed Prochak <edprochak_at_adelphia.net>
Date: Thu, 06 Mar 2003 21:07:05 GMT
Message-ID: <3E67BC26.7070508@adelphia.net>


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

>
>
> I think you missed the point, you stated exactly the contrary of my
> intentions, please read the message again.
>
> I am looking for a method of knowing whether a certain user has got any
> pending updates, other than using the usual "Has anything changed" flag at
> the client side and I thought it could be done via a query.
> I am just asking whether you think it is feasible or not, no more, no less.
>
> Thanks and bye,
> Flavio

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 frost
Received on Thu Mar 06 2003 - 15:07:05 CST

Original text of this message

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