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. Somehow
the object needs to be signaled to release the database connection
synchronously. The only other option would be to create a new member
function in the res object which can be called to accomplish the same.
>>> commit 0de7c2cf7e3f20634bda021b30511bcab4e6ff40
>>> Fix crashes when dbs_for_thread is zero
>This shows that the reuse_in_thread code isn't entirely sound. I think
>what is necessary to do there is to store the thread object both in
>SQLKey and SQLResKey, so that the destroy functions can access the
>right mapping regardless which thread they get called from. Of course,
>that also requires a bit of care to handle the concurrent access
>correctly.
>If that is implemented, then a useful debug tool would be to check
>that all functions (except destroy) really gets called from the
>expected thread.
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. I'll see if I can refactor this without the destructs
by introducing new member functions that actually free the database
connection for reuse.
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?
--
Sincerely,
Stephen R. van den Berg.
"Look, I CAME HERE FOR AN ARGUMENT!!" "OH, oh I'm sorry, but this is abuse."
"I see..." "You want room 12A, just along the corridor... Stupid git."
|