"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
becomes unreferenced.
> 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
> reuse.
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)
> instead?
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.
|