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