Not using beans, sessions possible anyway?

[Stefan Elfvinge]

My webapplication accesses a database both ways during a "session". Servlets communicate with the db with helperclasses- static methods querying and executing updates. Each servlet may query the db multiple times and each doGet() or doPost() ends with closing the db-connection(conn.close()).
(I have NOT implemented a connectionpool). Each servlet implements SingleThreadModel and they share only one connectionobject. The application will not be heavily used by too many clients at a time, so I thought this would be an easy way to work around the problem(SingleThreadModel and no connectionpool). A timer also runs for a certain time to track inactivity and close the connection if inactivity is the case. This whole approach is mostly due to still learning JDBC and Java.
That's the background, here's the first question:
Does this approach seem reasonable???
And the last question Iv'e seemed to ask too many people:
With the application working as stated above, exactly what will happen at browser-closing???
(If beans would have been used, to my knowledge, that could be considered the end of a session?)
A discussion/answer to these topics would really be a great help to my future coding/javalearning.
Once again, the reason for this approach is that I haven't yet learned JSP(my servlets print the HTML) or using beans.
Thanks

[Kevin Mukhar]

> Does this approach seem reasonable???
No. You claim that the "application will not be heavily used by too many clients at a time". That implies to me that it could be used by more than one client simultaneously. All you need is two or more clients to access the application simultaneously and you'll have a problem because, according to your post, the connection is shared. With a shared connection, two simultaneous clients will be using the same connection, and thus will interfere with each other.
The best technique is to use a connection pool, which ensures that each client gets its own connection.
If you don't want to use a connection pool, then make the connection a method variable of doGet() or doPost(). Thus, each request will get its own connection.
Also, SingleThreadModel is probably not the best choice either. It does not automatically make your servlet thread-safe, and it does not scale as well as a servlet that can handle multiple concurrent requests using threads.
> With the application working as stated above,
> exactly what will happen at browser-closing???
> (If beans would have been used, to my
> knowledge, that could be considered the end of
> a session?)
Yes, that will probably end the session as far as the browser is concerned. (Some browsers will maintain the session unless you close all browser windows.) However, the server is not notified of the browser-closing, so the server will maintain the session data until the session times out, or the server is stopped.

[Stefan Elfvinge]

Thanks!
I really have some things left to take care of.
How long til a server times out after browser-closing?
Does time out also meen garbage-collection?
I'll try to implement a connectionpool, but as it is now, shouldn't it work? I mean, each request actually ends with connection-closing and the next request asks the ConnectionManager for an open connection. Since it's closed and can only be used by one request at a time, the only problem I can see is that, yes, the all use the same connection-object.(???)

[David O'Meara]

This seems like more of a Servlet discussion than JDBC, I'm going to move it to the Servlet forum.
Dave.

[Anthony Villanueva]

How long til a server times out after browser-closing?
Does time out also meen garbage-collection?

The session will time out depending on the value set on setMaxInactiveInterval(int interval). According to the docs, it "... specifies the time, in seconds, between client requests before the servlet container will invalidate this session. A negative time indicates the session should never timeout."
I agree with Kevin. Using a connection pool will be more efficient. At least make your Connection object local to your doXXX() to make it thread-safe. The SingleThreadModel entails a bigger overhead as you are creating new servlet instances, so you may consider putting critical code inside synchronized blocks instead.

[Stefan Elfvinge]

Thanks again!
But synchronizing is "overhead", i.e. time-consuming, as well. I take it you mean it isn't as overhead as implementing SingleThreadModel(STM)??? Does "STM" use far more server/container-memory, because of more servletinstances, than the other approach?
/Steffe

[Anthony Villanueva]

Yes.
There is only one servlet instance per registered servlet. Normally, when concurrent requests are handled by the web server, threads are spawned which executes the service() method of the servlet.
According to the Servlet specs, when a servlet implements the SingleThreadModel interface (which is an empty "tag" interface) and concurrent requests are handled by the web server, the container is supposed to create a new servlet instance per request. It is possible that the container will pool these servlet instances. it is also possible that the container will serialize, i.e. queue, the requests per instance. It is possible that the container implementation is a combination of these.
So if your load is large, part of your processor time will be spent on constantly creating and garbage collecting these objects, called object churning. Any since your requests are (possibly) queued the performance will suffer.