Sessions in the lock list with no locks (0,0) 
Author Message
 Sessions in the lock list with no locks (0,0)
Hello everyone:

We are having a major locking problem here.
We have many sessions in the lock list with no locks (0,0).
When doing a commit, aren't they supposed to be removed from
the lock list?

Also, what else can cause a session to remain in the lock list without
locks.
A set session where lock=nolock perhaps?

We are II 2.0/0001 with patch 6854 running on an alpha GS80
under Tru64 Unix 5.1

Thanks very much for your help.

Bruce Crisp
National Library of Canada



Mon, 25 Oct 2004 22:13:23 GMT
 Sessions in the lock list with no locks (0,0)


Quote:

>We are having a major locking problem here.
>We have many sessions in the lock list with no locks (0,0).
>When doing a commit, aren't they supposed to be removed from
>the lock list?

>Also, what else can cause a session to remain in the lock list without
>locks.
>A set session where lock=nolock perhaps?

That is almost certainly it.  Sessions running in readlock=nolock and
doing selects with no commit.

The extra lock lists are a pain when trying to use ipm to track *real*
locking problems.  I don't see that they are a problem by themselves,
except as an indicator of dirty code that is missing commits.

--

K/B Computer Associates       www.kbcomputer.com
Ingres, Unix, VMS             Consulting and Training



Tue, 26 Oct 2004 00:47:59 GMT
 Sessions in the lock list with no locks (0,0)
Hi Karl and Roy:

Thanks very much for confirming this and for the additional info below!
Our developpers have reviewed their code and found many instances of
missing commit statements.

Since the problem appears to reside within the application we'll wait until
the
code is fixed and see if that helps, i.e. helps prevent some of our
users form being caught in a lengthy wait states.  

Bruce

Quote:
>Karl said:  That is almost certainly it.  Sessions running in
readlock=nolock
>and doing selects with no commit.
>The extra lock lists are a pain when trying to use ipm to track *real*
>locking problems.  I don't see that they are a problem by themselves,
>except as an indicator of dirty code that is missing commits.
>Roy said: Beware of logical inconsistencies in the reports due to the use

of IMA to produce those reports.  >IPM and lockstat read the list of
locklists from IMA and then the list of locks. Because all IMA queries
Quote:
>necessarily use dirty reads it is possible that the locks were released

while the report was being generated.
Quote:
>Unless there is good reason to suppose these sessions are causing a

problem, or they persist significantly
Quote:
>long, I suspect they are benign.  What is the nature of your "major locking
problem"?
>(Incidentally, a session using readlock=nolock does actually take locks,

but they are null (NL) locks.)
Quote:

>We are having a major locking problem here.
>We have many sessions in the lock list with no locks (0,0).
>When doing a commit, aren't they supposed to be removed from
>the lock list?
>Also, what else can cause a session to remain in the lock list without
>locks.
>A set session where lock=nolock perhaps?
>We are II 2.0/0001 with patch 6854 running on an alpha GS80
>under Tru64 Unix 5.1



Tue, 26 Oct 2004 02:06:22 GMT
 Sessions in the lock list with no locks (0,0)
I believe that IPM is still using LG and LK calls which directly access the
datastructures in the LG and LK components...

Assuming this is still true, IPM does not leave "ghosts" due to obtaining
locklists.  IPM does access iidbdb to get database names and will access
each database to query iirelation to get table names.

Hope this helps.

Tom Turchioe
IPM author


Quote:
> Hello everyone:

> We are having a major locking problem here.
> We have many sessions in the lock list with no locks (0,0).
> When doing a commit, aren't they supposed to be removed from
> the lock list?

> Also, what else can cause a session to remain in the lock list without
> locks.
> A set session where lock=nolock perhaps?

> We are II 2.0/0001 with patch 6854 running on an alpha GS80
> under Tru64 Unix 5.1

> Thanks very much for your help.

> Bruce Crisp
> National Library of Canada



Fri, 29 Oct 2004 19:17:45 GMT
 Sessions in the lock list with no locks (0,0)
Thanks for this info.  Bruce

(Things have improved here re our locking problem.  The application
code hasn't yet been fulling corrected (re addition of commits)
but at least we no longer have lots of users queued up in wait state.)

Quote:
-----Original Message-----

Sent: Monday, May 13, 2002 7:18 AM

Subject: Re: Sessions in the lock list with no locks (0,0)

I believe that IPM is still using LG and LK calls which directly access the
datastructures in the LG and LK components...

Assuming this is still true, IPM does not leave "ghosts" due to obtaining
locklists.  IPM does access iidbdb to get database names and will access
each database to query iirelation to get table names.

Hope this helps.

Tom Turchioe
IPM author



> Hello everyone:

> We are having a major locking problem here.
> We have many sessions in the lock list with no locks (0,0).
> When doing a commit, aren't they supposed to be removed from
> the lock list?

> Also, what else can cause a session to remain in the lock list without
> locks.
> A set session where lock=nolock perhaps?

> We are II 2.0/0001 with patch 6854 running on an alpha GS80
> under Tru64 Unix 5.1

> Thanks very much for your help.

> Bruce Crisp
> National Library of Canada



Sat, 30 Oct 2004 21:44:34 GMT
 Sessions in the lock list with no locks (0,0)


Quote:
>Thanks for this info.  Bruce

>(Things have improved here re our locking problem.  The application
>code hasn't yet been fulling corrected (re addition of commits)
>but at least we no longer have lots of users queued up in wait state.)

WARNING: this is an openly commercial message.  Vendor hype starts now:

Glad to hear it Bruce.  It is probably of little interest to you at this point,
but undisciplined transaction management is a leading cause of performance
problems and logical database inconsistencies among many of my clients,
depending on which way the programmers err.  Karl Schendel and I therefore
devote an entire chapter (nearly half a day) to this topic in our
<http://www.rationalcommerce.com/courses.htm>Advanced Ingres Programming
course.

Transaction management is not rocket-science, and it is very easy to get right
if you impose an almost trivial programming standard.  One thing that often
puzzles me is the convoluted and burdensome solutions I see, none of which
really have any hope of working.  A few are just plain mad.  Others have given
up even trying.  There really is no need for it.

End of hype.

Roy Hann
<http://www.rationalcommerce.com/>Rational Commerce Ltd.
"Ingres development, tuning, and training experts"



Sun, 31 Oct 2004 20:29:27 GMT
 
 [ 6 post ] 

 Relevant Pages 

1. Sessions in the lock list with no locks (0,0)

2. SQL7 session hangs, bogus index lock?

3. Record locked by current session

4. Sessions, threads, locks in isapi

5. Record locking from a EJB session bean

6. sessions and locks on procedures

7. Kill session and ORACLE does not free locks...

8. dead(locked?) sessions

9. Locking: Matching up sessions

10. Killed Session locks table, but has no process (spid)

11. ORACLE LOCKED SESSION HELP

12. How do kill a locked session


 
Powered by phpBB® Forum Software