Tim Bunce wrote:
> On Thu, May 02, 2002 at 04:56:02PM +0800, Stas Bekman wrote:
>
>>Tim Bunce wrote:
>>
>>
>>>>>>to take this a step further, what would be really DWIMy is for DBI to clear all
>of the
>>>>>>$dbh attributes not specified in the connect() call (including stuff like
>LongReadLen) if
>>>>>>dbi_connect_method = 'Apache'. that seems like the right thing, since with
>Apache::DBI
>>>>>>wat we want a "new" $dbh, just without the connect overhead. and DBI seems like
>a
>>>>>>reasonable place to do it, especially since DBI->connect is kinda
>action-at-a-distance
>>>>>>anyway wrt Apache::DBI.
>>>>>>
>>>>>>maybe I'm missing something design-wise, though?
>>>>>
>>>>>I think the Apache::DBI subclass can override the STORE method and
>>>>>track attribute changes itself.
>>>>
>>>>That sounds like a good solution. Edmund?
>>>>
>>>>I raised this issue, since in the mod_perl book Eric and I are working
>>>>on, we say that the connect string shouldn't change in order to be able
>>>>to reuse connections.
>>>
>>>
>>>s/connect string/connect string and username and password and attributes/ :)
>>>
>>>
>>>
>>>>I guess we must warn users that any changes to
>>>>$dbh will persist, which renders the advisory useless and doesn't
>>>>provide any solution :(
>>>
>>>
>>>The advisory is still valid - it just needs to be extended so say
>>>that if they modify an attribute after the connect then they should
>>>restore it... or wait for a version of Apache::DBI that'll do that for them :)
>>
>>Thanks Tim,
>>
>>Is it possible to simply localize the hash elements? Will this work
>>properly?
>>
>> {
>> my $dbh = DBI->connect(@connect) || die $DBI::errstr;
>>
>> print "LongReadLen is: ", $dbh->{LongReadLen}, "\n";
>> local $dbh->{LongReadLen} = 40;
>> print "LongReadLen is now: ", $dbh->{LongReadLen}, "\n";
>> }
>>
>> my $dbh = DBI->connect(@connect) || die $DBI::errstr;
>>
>> print "LongReadLen for new dbh is: ", $dbh->{LongReadLen}, "\n";
>>
>>If localization works, that's probably the best solution, that can be
>>applied by users.
>
>
> Yes, that'll work. But in some versions of perl it leaks memory
> (including 5.005 and 5.006, not sure about 5.5.3 and 5.6.1 or later).
Is it a perl tie mechanism's problem or DBI's? what about 5.8.0-tobe? Do
you know of a version that doesn't leak?
I've tested with Apache::Leak, the above block { } is reported to leak:
ENTER: 35222 SVs
new 0x8606a34 : SV = PVMG(0x8606480) at 0x8606a34
REFCNT = 1
FLAGS = (GMG,SMG,RMG,pIOK,pNOK)
IV = 40
NV = 40
PV = 0
MAGIC = 0x8606fc8
MG_VIRTUAL = &PL_vtbl_packelem
MG_TYPE = 'p'
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x857361c
SV = RV(0x8115920) at 0x857361c
REFCNT = 152
FLAGS = (ROK)
RV = 0x8573574
MG_LEN = -2
MG_PTR = 0x86069e0 => HEf_SVKEY
SV = PV(0x8604ef8) at 0x86069e0
REFCNT = 1
FLAGS = (POK,pPOK)
PV = 0x8606fb8 "LongReadLen"\0
CUR = 11
LEN = 12
new 0x8606a40 : SV = NULL(0x0) at 0x8606a40
REFCNT = 1
FLAGS = (PADBUSY,PADMY)
LEAVE: 35224 SVs
!!! 2 SVs leaked !!!
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
