"Stephen R. van den Berg" <[email protected]> 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.
