"Stephen R. van den Berg" <<srb[at]cuci.nl>> wrote:
> Martin Stjernholm wrote:
>>>> commit 6e6d1043c883d143682cd110f34b8cf994c245dd
>>>> Avoid long lingering database connections
>>The destructs in the second patch are risky - the result objects
>>should be acyclic instead.
> The trouble is that garbage collection might be to far off.
That's why it should be acyclic, so it gets reaped immediately when it
> I think that is the wrong diagnosis. I see your train of thought, but
> the problems are elsewhere (primarily), the problem is the fact that
> the time of release/reuse of the connection is determined by the garbage
> collector. Been there, got the T-shirt, that's why my code was littered
> with destruct()s.
Or you keep it acyclic. That's why acyclic structures rock.
> I'll see if I can refactor this without the destructs by introducing
> new member functions that actually free the database connection for
In light of the recent gc discussion on pike-devel, that could be a
good idea - in some future acyclic structures might not rock anymore..
> But, on a related note, the solution you propose here is to bind the
> database session to a Pike-thread. Whereas, quite possibly, in the future
> multiple threads could be parsing a single RXML page? Shouldn't the
> database session be bound to the id variable (i.e. RXML session)
Multiple threads can already parse the same rxml page, but what you
say wouldn't make any difference in that regard: An rxml parse session
never switch threads - it's only a more limited scope.
You suggest binding it to the id object. Please note that that's a
larger scope than an rxml parse session. The handling of a request can
(very rarely) switch threads, so yes, it could be an alternative to
bind it to the id object instead.
The problem is mainly to figure out a good API for it - the DBManager
cannot provide that service since it's on a lower level. And just
storing the db connection into some common place like id->misc->dbcon
as a matter of standard procedure could be dangerous - sometimes id
objects can live longer than usual, although that's rare too.