Martin Stjernholm wrote:
>"Stephen R. van den Berg" <<srb[at]cuci.nl>> wrote:
>> 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.
I'd say it is imperative to guarantee the same database session
to the RXML programmer, so even the slightest doubt about not
staying with the same Pike thread in an RXML session needs to
>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.
Wouldn't a longer living id object actually make it desirable to provide
the same SQL sessions alongside with it?
I've cleaned up my old patches using ideas from your reuse-in-thread
solution, and am currently debugging that. As soon as I have it working,
I'll see what the cleanest API could be.
Stephen R. van den Berg.
If there's a hard way to do something, I'm there before anyone else.