Re: Row-X (SX) lock on materialized view

From: Mark D Powell <Mark.Powell_at_eds.com>
Date: Thu, 4 Jun 2009 09:34:16 -0700 (PDT)
Message-ID: <5ae28d73-ae5a-4bc9-ac07-c21a81fcbd57_at_n4g2000vba.googlegroups.com>



On Jun 3, 5:04 pm, yf..._at_vtn1.victoria.tc.ca (Malcolm Dew-Jones) wrote:
> Mark D Powell (Mark.Pow..._at_eds.com) wrote:
> : On Jun 3, 1:27=A0pm, yf..._at_vtn1.victoria.tc.ca (Malcolm Dew-Jones): wrote:
>
> : > Of course my subject is wrong, the lock is on the LOG (on the master
> : > database), not on the materialized view on the other database.
> : >
> : > Malcolm Dew-Jones (yf..._at_vtn1.victoria.tc.ca) wrote: : I am examining a
> : >
> : > database. =A0The tables are all replicated to a second : database every t=
> : en
> : > minutes (so the users can do ad-hoc queries without : touching the real
> : > database).
> : >
> : > : When the user's have a form open then the record they are editing is :
> : > locked. =A0I can run a query against v$lock (etc) and see who has what :
> : > tables locked. =A0Mostly, everything is as expected.
> : >
> : > : My question revolves around the following.
> : >
> : > : For one particular table, the materialized view log has also turned up
> : > in : the lock list some times (Row-X (SX), same ctime as the data table).=
> :  =A0
> : > I : haven't seen that for other tables.
> : >
> : > : Is that normal? =A0Perhaps the other snapshot logs are locked and I jus=
> : t :
> : > don't happen to see it ever. =A0Is this something that needs investigatin=
> : g?
> : >
> : > : Opinions welcome.
> : >
> : > : Thanks, Malcolm Dew-Jones
>
> : Oracle uses tables to hold the logs used to update the materialized
> : view so if you insert a new row into the base table then the log table
> : is also updated as part of your transaction.  If you rollback then
> : there is not log row to be copied to the materialized view.  This
> : seems normal to me though I currently have no materialized view using
> : refresh logs to check against.
>
> : Being that writers do not block readers why does it matter?  Is this
> : just the first time you remember seeing the assoicated locks or was
> : something happening that you were checking into when you saw this?
>
> I have been asked to check why an application has locking issues, so I am
> investigating that.
>
> One key table typically has a dozen row locks (users editing in the main
> form of the app), and a few other tables also turn up regularly.  All of
> those tables have corresponding MLOG$_x tables, but Of those tables, I
> have only seen one (now two) that ever show a corresponding lock on their
> corresponding MLOG$_x table, I was not sure why this should be so.
>
> Forms locks a row when the user edits the fields in the form, but nothing
> in the database changes until they save, at which point the data is
> committed as well, so I guess that any lock on the MLOG$_x would only be
> for that breif period between the UPDATE and the COMMIT, so I guess it
> makes sense that I never normally see locks on the MLOG$_x tables.
>
> So I guess as I think out loud, that that must mean that the unusual table
> (that shows a lock on the MLOG$_x)  has had an UPDATE (generating a lock
> on its MLOG$_x) but has not yet had a COMMIT.  Since the forms interface
> always COMMITS as part of the UPDATE or INSERT that it generates, then
> there must be some other code in here that is doing an UPDATE (or INSERT)
> against that one table outside of the normal edit/save/commit cycle of
> oracle forms.
>
> As for "writers do not block readers why does it matter?", reading is not
> a problem, but writing is - when many people are using the application
> then apparently there are times when "everybody" is locked up. I never
> entirely trust peoples descriptions of their problems, but I suspect that
> what is happening at least part of the time is that one user, while
> filling in a form, causes code to run that does an INSERT that is not
> committed, and that that insert then prevents the next user from
> completing an INSERT into that same table, and that makes it appear as if
> the application is hung (which it is, sort of).  Unlike when multiple
> people try to edit the same row at the same time, there is no built in way
> to detect the insert issue ahead of time (unlike SELECT FOR UPDATE
> NOWAIT), and no way to do anything in the form (such as show an error -
> "Sorry, you waiting for someone else to commit before your insert will
> procede").
>
> I'm not sure (yet) how this situation is best viewed in the various
> session locking tables to try to confirm this and confirm which tables
> might be involved, it doesn't appear to turn up as a normal lock, but
> perhaps that's because that is not the problem, or perhaps I simply don't
> know enough yet.
>
> $0.10

Thank you for the update. Question, now I am not a coder but our java coders have had to disable the normal automatic commit that java issues after every statement in order to create transactions with several table updates all included in order to construct proper units of work. I believe that web based Forms also offers this option. Does the Form in question have programmer controled transactions?

The reason I mention this is if you disable the feature in one portion of the Form it may requrie the developer to code something different elsewhere in the Form that was forgotten, that is, issuing a manual commit or turning auto-commit back on.

This is the only idea that comes to mind.

HTH -- Mark D Powell -- Received on Thu Jun 04 2009 - 11:34:16 CDT

Original text of this message