RE: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)

 



From: [email protected]
To: [email protected]
CC: [email protected]; [email protected]; [email protected]
Subject: RE: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
Date: Fri, 31 Jan 2014 18:04:44 -0500




 Opp hit send too fast

 
> Date: Fri, 31 Jan 2014 22:09:02 +0000
> From: [email protected]
> To: [email protected]
> CC: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
> Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
> 
> On Fri, Jan 31, 2014 at 12:50:36PM -0500, John Scoles wrote:
> > Well I did do some testing. The leak was very small (1k over 10 min run) but only when one does
> > $shift->FETCH( 'ParamValues' ),
> > in the child callback.
> 
 
With of course the older DBI <1.63, 
 
 I did not see a leak with 1.63  no matter how long I let it run

> If it doesn't keep growing with more call then it's not a leak.
> 
> > Tim what would the impact of the above?? I know before 1.63 this
> > $shift->{ParamValues'},
> > gave you undef which is why the WTF comment was there.
> 
> Because the inner handle is a plain blessed hash ref, whereas the outer
> handle is *tied* blessed hash ref.
> 
> There's no 'ParamValues' key in that hash, so you get an undef.
> 
> The ParamValues lookup is handled by the FETCH method call.
> 
> > Why if in the CB we had the outter handle would the FETCH give you the attributes of the Inner handle??
> 
> Calling $outer->{ParamValues} in a tied hash ref triggers a call to
> $outer->FETCH('ParamValues') which then gets dispatched by the DBI to
> $inner->FETCH('ParamValues') which does the work.
> 
 
In pre 1.63 in the callback it  would be like this;
 
Calling $inner->{ParamValues}  = undef;

calling  $inner->FETCH('ParamValues') which does the work.
 
OK

> 
$inner->{ParamValues} 
 
 

> For more details see http://perldoc.perl.org/perltie.html
> 
> > Just a silly question?
> 
> No such thing :)
> 
> Tim.
> 
> > Cheers
> > 
> > 
> > 
> > > Date: Fri, 31 Jan 2014 17:00:20 +0000
> > > From: [email protected]
> > > To: [email protected]; [email protected]
> > > CC: [email protected]; [email protected]; [email protected]
> > > Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
> > >
> > > On 31/01/14 16:21, Tim Bunce wrote:
> > > > On Fri, Jan 31, 2014 at 09:11:28AM -0500, John Scoles wrote:
> > > >> A final note on this.
> > > >>
> > > >> Seems there was a very very long unknown bug in DBI which was only fix a few days ago wiht DB
> > 1.6.31
> > > >
> > > > If you mean Callbacks getting an inner handle, that wasn't a bug as such.
> > > > More like a design choice that proved non-optimal.
> > > >
> > > >> [1]http://blogs.perl.org/mt/mt.fcgi?__mode=view&_type=entry&id=5570&blog_id=2165
> > > >
> > > > That's http://blogs.perl.org/users/byterock/2014/01/callbacks-ate-my-brain.html
> > > > I presume.
> > > >
> > > >> The end result of this bug was that when callbacks are used on the
> > > >> statement handle some attributes will not be there so you
> > > >> programmer who did this
> > > >>
> > > >> $sth->FETCH( 'ParamValues' ), # WTF? - returns a reference to an array of hashes
> > > >>
> > > >> was most likely complaing that the
> > > >>
> > > >> $sth->{ParamValues},
> > > >>
> > > >> should return a ref but was just returning undef.
> > > >>
> > > >> So he 'Kludged' the code to get the value directly with the FETCH which works
> > > >
> > > > I'm not sure what you're saying here John. Using $sth->FETCH('ParamValues')
> > > > is perfectly reasonable. It was required before 1.631 and optional with
> > > > 1.631+ now that $h->{ParamValues} works.
> > > >
> > > >> sort of, but it does bleed memory every so slighly.
> > > >
> > > > Are you sure? This is the first I've heard of such a leak.
> > > >
> > > > Tim.
> > >
> > > I've found no evidence of a memory leak with a simple test calling ParamValues a lot with some
> > parameters. However, I'm not using ORA_VARCHAR2_TABLE. The code is:
> > >
> > > else if (kl==11 && strEQ(key, "ParamValues")) {
> > > HV *pvhv = newHV();
> > > if (imp_sth->all_params_hv) {
> > > SV *sv;
> > > char *key;
> > > I32 keylen;
> > > hv_iterinit(imp_sth->all_params_hv);
> > > while ( (sv = hv_iternextsv(imp_sth->all_params_hv, &key, &keylen)) ) {
> > > phs_t *phs = (phs_t*)(void*)SvPVX(sv); /* placeholder struct */
> > > (void)hv_store(pvhv, key, keylen, newSVsv(phs->sv), 0);
> > > }
> > > }
> > > retsv = newRV_noinc((SV*)pvhv);
> > > cacheit = FALSE;
> > >
> > > }
> > >
> > > which looks sane to me right now. ORA_VARCHAR2_TABLE seems to do strange things with parameters I
> > don't quite get right now.
> > >
> > > As I said previously to H�lder and John (some of the discussion was off dbi-users list presumably
> > because it contained log data), although I accept taking the call to ParamValues out has on this
> > occasion made the problem go away I don't understand why. I think there is more to this than it so far
> > looks but without a way of reproducing it myself I won't be spending any more time on it. If it is
> > reproducible in a standalone script I will happily look again.
> > >
> > > Martin