Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / Ingres Topics / June 2004

Tip: Looking for answers? Try searching our database.

maxlocks not being honoured on HASH tables

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
David Morgan - 24 Jun 2004 21:11 GMT
I've noticed a problem on one of my production databases where the ING_SET
maxlocks=100 symbol table entry is being ignored by some tables and indexes.

With these objects, page locks escalate to table locks after the default 10
page locks have been taken. The only common factor I can see is that the
storage structure is HASH. Has anyone else seen this problem?

II2.6/0305 on AIX

Signature

David

Roy Hann - 25 Jun 2004 13:09 GMT
> I've noticed a problem on one of my production databases where the ING_SET
> maxlocks=100 symbol table entry is being ignored by some tables and indexes.
>
> With these objects, page locks escalate to table locks after the default 10
> page locks have been taken. The only common factor I can see is that the
> storage structure is HASH. Has anyone else seen this problem?

Can you be sure the session that is taking the locks belongs to a client app
running on the same host where ING_SET is set?

In 2.6 it is probably far preferable to configure system_maxlocks=100 using
CBF rather than relying on environment variables.  That way you know
everyone us using the same setting.

Roy Hann (rhann at rationalcommerce dot com)
Rational Commerce Ltd.
www.rationalcommerce.com
"Ingres development, tuning, and training experts"
David Morgan - 26 Jun 2004 20:09 GMT
> Can you be sure the session that is taking the locks belongs to a
> client app running on the same host where ING_SET is set?

My mistake - now fixed.

I thought I had eliminated client sessions from other sources. However the
session (daemon process) that I've now identified as the culprit is running
on the same host, but it's a java app and connecting via the Ingres JDBC
server.

Signature

David

 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.