Semantics of InactiveDestroy

Hi!

I have a problem with parsing the documentation regarding the
"InactiveDestroy" attribute on DB handles.

Citing the documentation:

"InactiveDestroy" (boolean)
The "InactiveDestroy" attribute can be used to disable the *database
engine* related effect of DESTROYing a handle (which would normally
close a prepared statement or disconnect from the database etc). The
default value, false, means a handle will be fully destroyed when it
passes out of scope.

For a database handle, this attribute does not disable an *explicit*
call to the disconnect method, only the implicit call from DESTROY
that happens if the handle is still marked as "Active".

Think of the name as meaning 'treat the handle as not-Active in the
DESTROY method'.

This attribute is specifically designed for use in Unix applications
that "fork" child processes. Either the parent or the child process,
but not both, should set "InactiveDestroy" on all their shared
handles. Note that some databases, including Oracle, don't support
passing a database connection across a fork.

To help tracing applications using fork the process id is shown in
the trace log whenever a DBI or handle trace() method is called. The
process id also shown for *every* method call if the DBI trace level
(not handle trace level) is set high enough to show the trace from
the DBI's method dispatcher, e.g. >= 9.


What's missing here is a more detailed description of what actually
happens if I set it to non-default value (which is more interesting).

I suspect by negation, that setting it to "true" would fully destroy the
handle (or partly) destroy the handle when it goes out of scope, but
there should be a clear explanation what it actually does.

I'm actually quite confused by this fragment of documentation, since the
attribute name suggests that it enables destroying, while the
documentation suggests that it does the reverse.

Could anyone clarify what are effects of setting this attribute to true
(and possibly change it in the documentation)?

--
Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575
http://olo.ab.altkom.pl

RE: Semantics of InactiveDestroy

> -----Original Message-----
> From: Aleksander Adamowski [mailto:aleksander.adamowski.dbi@altkom.pl]

> Sent: Tuesday, April 18, 2006 4:39 AM
> To: dbi-users@perl.org
> Subject: Semantics of InactiveDestroy
>=20
> Hi!
>=20
> I have a problem with parsing the documentation regarding the
> "InactiveDestroy" attribute on DB handles.
>
> Citing the documentation:
>
> "InactiveDestroy" (boolean) The "InactiveDestroy" attribute can be
> used to disable the *database engine* related effect of DESTROYing
> a handle (which would normally close a prepared statement or
> disconnect from the database etc). The default value, false, means
> a handle will be fully destroyed when it passes out of scope.
>
> For a database handle, this attribute does not disable an
> *explicit* call to the disconnect method, only the implicit
> call from DESTROY that happens if the handle is still marked
> as "Active".
>
> Think of the name as meaning 'treat the handle as not-Active
> in the DESTROY method'.
>
> This attribute is specifically designed for use in Unix
> applications that "fork" child processes. Either the parent or
> the child process, but not both, should set "InactiveDestroy"
> on all their shared handles. Note that some databases,
> including Oracle, don't support passing a database connection
> across a fork.
>
> To help tracing applications using fork the process id is
> shown in the trace log whenever a DBI or handle trace() method
> is called. The process id also shown for *every* method call
> if the DBI trace level (not handle trace level) is set high
> enough to show the trace from the DBI's method dispatcher,
> e.g. >=3D 9.
>
>
> What's missing here is a more detailed description of what actually
> happens if I set it to non-default value (which is more interesting).
>
> I suspect by negation, that setting it to "true" would fully destroy
> the handle (or partly) destroy the handle when it goes out of scope,
> but there should be a clear explanation what it actually does.

It's actually the reverse. It means, in practice, "don't *automatically*
call disconnect() when the $dbh is destroyed". It can save you from some
pretty nasty trouble when you fork processes. You don't want your child
process exiting to close your parent's database connection. That's what
this solves.

$dbh->{InactiveDestroy} =3D 1; # safe(r) for forking

Philip