Subject | Re: [firebird-support] Events and non-intrusive, opt-in, server-side fulltext-search |
---|---|
Author | Daniel Albuschat |
Post date | 2005-03-11T11:14:58Z |
On Fri, 11 Mar 2005 11:49:30 +0100, Martijn Tonies <m.tonies@...> wrote:
"block the server" is quite a strong statement.
Yes, the UDF will block. But the only UDF-call that might take up
some time is the fts_find call, which is nested in the stored
select-proc's select loop, which sounds like pretty reasonable
place to put a blocking UDF.
A select blocks as long as the select takes, after all.
I'd imagine this set of UDFs:
fts_open // opens a handle. Might even be implemented asynchronously (that is,
// the real connection will be established on the first
fts_find call for this handle)
fts_find // requests a search result from the fts-server. This may
take some time.
fts_close // closes the handle, counterpart to fts_open
fts_update // adds an update action to the command queue. non-blocking
fts_insert // adds an insert action to the command queue, non-blocking
fts_delete // adds a delete action to the command queue, non-blocking
The actual network-connection to the fts-server will be established on module
creation and released on module-deinitialisation, I guess. Perhaps threaded,
so module initialisation is not blocking either. Module-deinitialisation has
to block while closing the connection, though, obviously.
But well, I'll still have to reinvestigate this issue, since I'm not sure about
module loading and deloading in FB.
This looks like a pretty robust setup to me.
Any objections?
cu,
Daniel
--
eat(this); // delicious suicide
> As long as the procedure is caling the UDF, it will block, right?Thanks for your quick answers, Martijn.
> Depending on the task the UDF is performing, this may or may
> not block the server.
"block the server" is quite a strong statement.
Yes, the UDF will block. But the only UDF-call that might take up
some time is the fts_find call, which is nested in the stored
select-proc's select loop, which sounds like pretty reasonable
place to put a blocking UDF.
A select blocks as long as the select takes, after all.
I'd imagine this set of UDFs:
fts_open // opens a handle. Might even be implemented asynchronously (that is,
// the real connection will be established on the first
fts_find call for this handle)
fts_find // requests a search result from the fts-server. This may
take some time.
fts_close // closes the handle, counterpart to fts_open
fts_update // adds an update action to the command queue. non-blocking
fts_insert // adds an insert action to the command queue, non-blocking
fts_delete // adds a delete action to the command queue, non-blocking
The actual network-connection to the fts-server will be established on module
creation and released on module-deinitialisation, I guess. Perhaps threaded,
so module initialisation is not blocking either. Module-deinitialisation has
to block while closing the connection, though, obviously.
But well, I'll still have to reinvestigate this issue, since I'm not sure about
module loading and deloading in FB.
This looks like a pretty robust setup to me.
Any objections?
cu,
Daniel
--
eat(this); // delicious suicide