PEPPLER.ORG
Michael Peppler
Sybase Consulting
Menu
Home
Sybase on Linux
Install Guide for Sybase on Linux
General Sybase Resources
General Perl Resources
Freeware
Sybperl
Sybase::Simple
DBD::Sybase
BCP Tool
Bug Tracker
Mailing List Archive
Downloads Directory
FAQs
Sybase on Linux FAQ
Sybperl FAQ
Personal
Michael Peppler's resume

sybperl-l Archive

Up    Prev    Next    

From: "Athey, Keith" <Keith dot Athey at twc dot state dot tx dot us>
Subject: RE: shared locks and connections
Date: Mar 2 1998 6:53PM

I ran into a similar problem when interfacing with Gupta ( bleck ) a
while ago.  In my case the client side was not sending a "commit tran"
and thus not releasing the resource.  We solved the problem by
explicitly sending a commit tran call within the Gupta code after each
call to the database.

See chapter 17 of the Sybase SQL Server Transact-SQL User's Guide for
more than you'll ever want to know on the subject.

> -----Original Message-----
> From:	Chuck Griffith [SMTP:griffch@startribune.com]
> Sent:	Monday, March 02, 1998 11:12 AM
> To:	SYBPERL-L@trln.lib.unc.edu
> Subject:	Re: shared locks and connections
> 
> At 5:12 PM -0600 2/27/98, Michael Peppler wrote:
> >Well - theoretically as all the programs are doing is 'select's there
> >shouldn't be any lock contention at all. The issue is the programs
> that
> >you have that are writing to the same tables, and how they run.
> 
> When a select is executed, the server does a shared intent lock on all
> the retrieved rows. This means that someone else can read them but not
> update or delete them until all the rows are retrieved.
> 
> My assumption is that all these locks are released after the last row
> is
> retrieved but we are seeing such strange performance problems that one
> has to wonder if it is keeping the locks until the connection is
> closed.
> 
> ----------------------------------------------------------------------
> --
> Chuck Griffith
> 612-673-4105
>