>>> "Schmidt, Allen J." <[EMAIL PROTECTED]> 3/30/99 3:39:10 PM >>>
>You can add what you feel
>is relevant back to the list if you want to.

Ok, but most of this is already on the archives, and hopefully soon
in the FAQ. If it's ok with you I'd like to put some of this in the
FAQ?

>Is the default persistence the 30 minutes I have heard about? I am
running
>the development web server that JRun is installed on (IIS3). Is it
>controlled by IIS or JRun?

I don't know about JRUN (I use my own servlet server called
Paperclips) but servlets are persistent forever, until either the
administrator kills them or the server falls over.

The basic process from an admin point of view is this:

1.Admin starts servlet engine.
2.Admin loads up whatever servlets he wants into the server

At stage 2 is when your servlet is being run. However it doesn't do
anything really, just sites there forever waiting for a Thread to run
it's .service() method.

>Our mainframe operators noted that the "user" logs on and the
transaction
>runs and then it appears that they log off. There is no CICS logoff
>component within my servlet. Is there a new thread or servlet
instance
>created everytime I run the servlet? Even from the same browser? How
is that
>handled?

Yes, you've got it.

This is the process basically.

1.The web server (or servlet engine, or servlet server, whatever you
want to call it) recieves a TCP connection on port 80 (or 8080 or
whatever).
2. it starts a new thread and hands the connection (in the form of a
TCP socket) to handler code.
3. the web server can then go back and receive another request and
create another thread etc...
4. the handler code works out what servlet needs to get the
connection by looking at the url path.
5. when the handler code works out what servlet it needs to pass the
request to it creates an HttpServletRequest and an HttpServletResponse
object to represent the connection and calls the servlets .service()
method.
6. when the .service() method (or doGet() or whatever) has completed
the thread dies.

This is conceptually how it works. You have to imagine lots of
threads all running your .service() method simultaneously. A good book
on threading is very usefull to understanding the servlet
environment.

Any data within the scope of your .service() method is thread safe.
But data in the scope of the entire servlet is not Thread safe and you
have to carefully synchronise access to it.

Javasoft have a tutorial on Thread, I would read it if I were you.
It's on their web site somewhere.

>For security on other non-servlet based web transactions I have
developed, I
>was going to create a servlet to verify CICS security and pass that
>authentication back to the browser to allow them access to other
types of
>existing html pages. Would this work?

You can do web authentication and use CICS as your security registry.
The browser will remain web authenticated for as long as it is
running. The trouble with this is that you are transmitting your CICS
passwords over the Internet in (pretty much) clear text. There are
obviously quite a few issues with this.

If you need a quick guide to how authentication works with servlets
then look up:
http://www.tapsellferrier.co.uk/Servlets/FAQ/authentication.html

>BTW, I am placing my order for Jason's book as soon as my boss gets
in.
>Sounds like it will help a great deal.

It's a good book but I wish mine was published, then I could get you
to buy that. /8->

>I will also check the archives.

The archives are a great source of info, you do have to trawl but it
is all there.

However, I and others are always to help new users.

>Thanks for your help.

s'okay.




Nic Ferrier
Tapsell-Ferrier Ltd
www.tapsellferrier.co.uk

___________________________________________________________________________
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