|
Here is the blow-by-blow of this problem, in case you are
interested plus possible resolutions…. In GT::Eval::create_db_object, the current db connection is
reused if the $db variable is defined (the assumption the code is making here
is that if the variable is defined, then the connection to the data base
exists). When we disconnect from the data base, this variable is not
undefined, and thus, the attempt to reuse above fails, leaving us to access a
disconnected data base. There are two possible ways to deal with this issue: 1.
Move the responsibility of connecting/disconnecting from the
data base to each script (as it was before the factoring). 2.
Fix the manner in which the db reused by ensuring that we do not
attempt to reuse a disconnected data base. (1) has the advantage of giving the user more control over the
data base connects. E.g., in backtest.pl, we would not have to reconnect to the
database in order to perform the analysis report (Report.pm and Indicators/Prices.pm
are the only places where the reuse of the db connection would have any
impact). (2) has the advantage of hiding the db access completely from
the script writer. I have traced data base connections in the scripts through
example runs. It turns out that the only occasions where we have an additional
db connection due to the earlier disconnect under (2) are: backtest_multi.pl: One connect per market instead of one single
connect. backtest.pl: One additional connect for the report. I also discovered that there is an optimization possible in
Indicator/Prices which avoids reconnect to the data base, but that applies to
either scenario. Any preferences for (1) or (2)? Thanks, Th. From: Weigert, Thomas
[mailto:weigert
AT
mst.edu] I have installed beancounter and PG on my system to look at this
problem. It turns out that throughout GT there are locations where a data
base is reused via a shared “our” variable. While it appears when
one looks at the code that the $db reference is assigned to a “my”
variable, in fact the content of that variable is retrieved from the shared
reference. Therefore, the disconnect from the data base must be done only once,
as there are situations where the assumption is being made that the data base has
already been connected to. While this is not very safe, and not documented, it
does imply that we must make the assumption that the data base should be
connected to in the script and disconnected from at the end of the script. Commenting the disconnect out won’t do much harm, but the
better way will be to migrate the disconnect back into the scripts. On cygwin (the environment I am running, I am getting problems
with fork and db access, so there are issues with running scan.pl with
beancounter. Thus I have not been able to look at scan.pl, due to that problem.
Th. From: Nicholas Kuechler
[mailto:nkuechler
AT
gmail.com] With Roberts help, we found the
DB disconnect in GT/Tools.pm appears to be causing this problem. |