Subject Re: [firebird-support] Events and non-intrusive, opt-in, server-side fulltext-search
Author Daniel Albuschat
On Fri, 11 Mar 2005 11:49:30 +0100, Martijn Tonies <m.tonies@...> wrote:

> As long as the procedure is caling the UDF, it will block, right?
> Depending on the task the UDF is performing, this may or may
> not block the server.

Thanks for your quick answers, Martijn.

"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