On Thu, 23 Oct 2003, scott.marlowe wrote:
> It might be more efficient and transactionally safe to write it all to a
> temp table, and have a daemon suck that data out every now and then and
> put it into another database that the feeders can interrogate as often as
> they like. that way you still get the ease of programming a transaction
> that's all or nothing, and since the daemon only runs every minute or two
> and batches up its access, the impace of the batching should be nominal.
> Or would that introduce other problems of its own?
>
>
Makes the whole trigger alot more complex. Also got to work out
when to remove rows. Plus a load of programming to get notify to work
properly. Yuk.
I think the simplest way then is going to be. That your
surgesting.
Write Trigger to Write info to table and notify each row needs a unique
id.
Listening Program reads table and records another id to say its
listening and how far its got, Waits for notify then checks the table
again and records the id. Fortinally each transaction only emits one
notify no matter how many times notify got called.
Program three looks for all ids in table below the lowest id listen and
deletes them, this should keep the table small enough to use.
Where as my orignal plan was using a deffered after trigger emit
the data down a pipe then all the program needs to do is listen to the
pipe.
Both plans have advantages the main oneof mine being its simple.
Peter
Trying to follow a kiss policy.
