>>> "Rob L'Estrange" <[EMAIL PROTECTED]> 21-May-01 7:08:32 AM >>>

It's an interesting idea Rob

Some comments:

>2. There will be occasional performance hits when pools
>manage their size (particularly size increases) to suit demand.
>This can be managed to a certain extent with a healthy initial
>pool size (at the expense of greater memory usage of course).

True. I'd say this was your biggest problem. Thread pools do this but
creating thread objects is really quite a light operation.


>3. Our understanding is that not all servlet container vendors
>handle (or are required to handle) SingleThreadModel servlets
>in the same way (ie. by using pools). That means we're
>introducing a bit of vendor tie-in.

Most do handle things in this way.


>We don't view the consumption of additional memory as an issue.

Fine. I think that's a mistake personally. I view memory and proc
time as a precious resource however much money I have to spend on the
hardware. I find it's a usefull constraint.

Are you getting a real pay off in speed or simplicity by being this
radically different to the norm?

Remember also that higher memory utilization sometimes = higher proc
utilization (gc load).


>Our website is an ecommerce portal that will not be
>overly hit-intensive (it deals with plant equipment sales,
>rather than high volume stuff like small item sales to the
>general public).

Right. Still, doing it this way will cost you more than doing it in
the more conventional way.


>I'm after general feedback and thoughts from the group,

Personally I don't think it's a good idea. Yes: it's technically
possible. Yes: it might even be a good technical solution.

You mentioned most of the critisisms in your email, There's one
further critisism: Although you might think this makes sense to you
now it's not the generally accepted use of servlets. You're breaking
the simple: servlet==http-request-handler model; people coming after
you may have trouble understanding what you've done or why you've done
it like that. There's a financial cost (of developer time in
understanding nwhat's going on) involved with being unconventional.


Nic Ferrier

___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".

Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

Reply via email to