Re: Triggers, Stored Procedures, PHP. was: Re: PostgreSQL

Hi there,

> > > >Uh, how about threads. I know that you don't need them much but
> > > >it sure would be nice to be able to do background processing.
> > >
> > > PHP doesn't support threads?
> >
> > Nope...
> >
> > I've always thought of Forking as
> > > overkill where threads are light and elegant.
> >
> > Depends on your environment... Forking in Linux is fairly lightweight.
>
> But when you are using php with a web server you can't really use the
> process contol functions safely. Forking apache processes on your own is
> not a good idea. If forking were an option with php/apache it would do just
> fine. But currently it is not a viable solution.

Web applications should NEVER fork processes or create their own threads.
Period. Do this isn't safe in any environment, os, web server or development
tool. You can see on the J2EE specs that Servlets and EJBs are expressly
prohibited from doing this.

The reason is you should give the web server control of OS resources such as
threads and processes so it can get better performance, use caching and provide
a clean, robust and safe environment for hosted apps.

If you do have some background proccess that should be started from by web app,
but rum assyncronously, that is, the web app won't wait for it to be finished
before sending the reply to the user browser, it should send a message (or a
unix signal) to some eternal process (a daemon) who will perform this work.

That's the reason many "enterprise" development toolkits, like Java J2EE and
Microsoft .NET (or the older DNA) includes messaging middleware.

The same applies to database stored procedures and triggers.

A PHP script run outside the web server and a unix named pipe (or a TCP socket)
could do the trick. Some use a database table as a message queue, so a process
checks from time to time if there's new jobs awaiting on the queue.

[]s, Fernando Lozano