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

> > > 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.
> >
> > Is this true? I know lots of servelet developers (mostly using Tomcat)
that
> > do this all the time without encountering any problems. Could you point
me
> > to the part in the spec where it indicates that this is inappropriate?
>
> The fact it worked for your friends using Tomcat doesn't mean it isn't
wrong.
> Take for example IE rendering of CSS attributes. I don't have the J2EE and
> Servlet specs at hand to look at, but I'm sure I've read this.

I realize that. That is why I asked the question. I'm just saying that
when I hear people that I trust tell me that it is a common accepted
practice and then I hear someone else tell me otherwise I'm not just going
to take either side's opinion. Seeing the spec however would be nice
because next time I discuss it witha Java developer I could back up what I
was saying. (It would be especially nice when the developer is bashing php
for it's lack of thread support.)

> Last year I was talking with Jetty developers (another open source web
> container) and they realized they were'nt folowing the specs regarding to
> authentication. The specs are a very long document and hot easy to read
(or to
> locate some specific info), so it's easy to misinterpret them or to
forgive
> somethg, but some (application) developers never bothered to read it. Just
use
> trial and error until "something works". :-)

All the more reason not to take anyone's word at face value (your's or my
servelet writing friends') but rather to read the spec for myself.

> I can't imagine how a web server cannot be affected by apps creating
threads
> and/or proccesses. Think about memmory use, resource pooling,
syncronization
> issues, ... remember a child process ot thread prevents the termination of
its
> parent (which may become a zombie on Unix systems, and a zombie still
holds its
> open file handles). If these child threads are buggy they could get to the
> point the web server cannot accept new requests.

That fact that I know that this is being done regularly on widely deployed
entrprise wide applications for very, very large companies without even a
hint of a problem makes me think that your perception of the issue may be
slightly flawed. If you can't imagine how this would ever not cause huge
problems then I think you just might be missing something. The fact is, and
I have discussed the issue at length with the actual developers, is that it
works like a charm causing no noticible problems. The software is heavily
used and very mission critical.

> You may be lucky and never crash your server. But you may not be. The
> difference between reliable and unreliabe system is the first ones don't
leave
> it to lucky, they impose rigid standard on coding practices and won't do
things
> that "just work".

Which is why I feel that your analysis of the situation is missing
something. If they were relying on luck to not have their servers crash
they would notice. They have very, very reliable systems running mission
critical applications with high levels of usage and concurrency. In
addition it makes a lot of sense to me why forking an apache process would
cause all kind of problems. It does not make as much sense to me that
spawning a new thread inside of Tomcat (or any other servlet container)
would cause any more problems then spawning a thread inside of any other
application. Obviously it must be done correctly and carefully but I don't
see why when done right it should cause any problems.

I would be interested to read the spec sometime and check it out for myself.
Sometimes however searching for something that someone else says they are
"sure" that they have read is sometimes harder than finding something that
is actually there. I'm not saying that you are wrong I'm just saying that
what your saying doesn't match up at all with what I have experienced or
talked about with anyone else and thus I am suspicious of it.