Subject Author Date
Re: SQL-session reuse in thread Martin Stjernholm <mast[at]roxen[dot]com> 17-01-2009
"Stephen R. van den Berg" <<srb[at]>> 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.