Well, that sums it all up! Thanks for all your help.
/K
Den onsdag, 29 oktober 2014 20:32 skrev Tim Bunce :
On Wed, Oct 29, 2014 at 02:09:22PM +, Knal Astrfisson wrote:
> Yes, they most likely were implicitly started by the select
> statement. The lock is taken as a full-table IS
On Wed, Oct 29, 2014 at 02:09:22PM +, Knal Astrfisson wrote:
> Yes, they most likely were implicitly started by the select
> statement. The lock is taken as a full-table IS lock, which
> is a very normal result of the DB2 query optimizer.
>
> The question is why the lock is not released wh
Yes, they most likely were implicitly started by the select
statement. The lock is taken as a full-table IS lock, which
is a very normal result of the DB2 query optimizer.
The question is why the lock is not released when the statement
handle goes out of scope after having been ->finish and dest
On Tue, Oct 28, 2014 at 02:20:52PM +, Knal Astrfisson wrote:
> Hi,
>
> The problem: database locks are left behind after the statement
> handles of simple select statements are closed, e.g. $sth->finish;
> and undef $sth; when I fetch BLOB fields from DB2 using AutoCommit=0.
I'd guess tha
Hi,
The problem: database locks are left behind after the statement
handles of simple select statements are closed, e.g. $sth->finish;
and undef $sth; when I fetch BLOB fields from DB2 using AutoCommit=0.
Some hobby-analysis follows: I did some tracing in DBI and it after
the last call to fetc
