OE-3.5 Servlets, JSP & Database Connectivity

What this is and why it exists

This is where the language turns into a web application, and one abstraction sits at the centre of it: the servlet lifecycle.

A container creates your servlet, initialises it, services each request, and eventually destroys it. You write only the middle. Understanding that division explains most of what otherwise looks like magic.

The other governing fact is that the protocol has no memory. Every session-tracking approach exists to work around that one absence.

The vocabulary

• Servlet — a Java class that handles web requests.
• Container — the server-side program that manages servlets.
• Lifecycle — creation, initialisation, servicing, destruction.
• Request — what arrived, with its parameters and headers.
• Response — what you send back.
• Stateless — the protocol remembers nothing between requests.
• Session tracking — carrying identity from one request to the next.
• Servlet context — state shared across the whole application.
• JSP — a page of markup with Java inside it.

The mental model

The container owns the lifecycle. It creates your servlet once and initialises it once. It then calls it for each request, often on many threads at the same time, and destroys it at shutdown. You write the servicing method and, if needed, the initialisation.

That "many threads at the same time" is worth pausing on. One servlet instance serves concurrent requests, so anything you store in an instance field is shared between users. This is the race condition from the previous topic, arriving in the place where it does the most damage. Keep per-request state in local variables.

Request and response are the two objects the servicing method receives: what arrived, and what you will send back. Most servlet work is reading one and writing the other.

Then the memory problem. The protocol is stateless — each request arrives knowing nothing about the last. But an application needs to know that this request is from the same person as the previous one. The four standard approaches all solve that single problem in different ways, with different trade-offs in size, security and whether the browser cooperates. Learn them as four answers to one question, not as four topics.

The servlet context is application-wide shared state, which brings its own concurrency question and the same answer as before.

JSP is servlets written inside out. Instead of Java that emits markup, it is markup with Java in it — and it is compiled into a servlet anyway. Knowing that is what makes the generated code comprehensible when you eventually have to look at it, and you eventually will.

Connecting to a database from either one uses the same driver and connection model. The important habit belongs to the database module. Build queries with parameters rather than by joining strings, so user input can never become part of the statement.

What you should now be able to explain or do

Describe the servlet lifecycle and say which part you write. Say why one servlet instance serving concurrent requests makes instance fields dangerous. Read a request and write a response. Explain why session tracking exists at all, and compare the standard approaches as answers to one problem. Say what JSP is in terms of servlets. Connect to a database using parameters rather than assembled strings.

Check yourself