Daniel R�nnqvist wrote:
>
> Could someone give me some hints about the following things:
> - When should I close my resultsets, statements and connections in
> comparrison to commit (I use auto commit off) and each other ?
Close your connection (or free it back into your Connection pool) as soon as you
have finished with it. i.e. if you are doing a "SELECT" get your result set copy
the result set to some a collection class of your own (some kind of iterator) then
close your result set. That allows you to do some manipulation of the data that
your version of database driver may not allow and frees up the expensive resource
that is a result set. Then close (of free to the pool) your connection.
Connections are very expensive both in terms of time to create and in money. Many
database licenses are calculated in the amount of open connections to the database
that you can have and databases also have a limit to the maximum number that they
allow.
>
> - Would a connection pool servlet solve this problem ? I've read that
> connection pooling is buildt in in JDBC 2.0.
Because it takes so long to create a connection (sometimes a few seconds) the
scale ability (in terms of concurrency) of you application may be hit if each user
had to wait to create a connection and there was a limit on the number of
connections (Oracle can take 50 connections I believe - I'm ready to be corrected
on this number :-) a bottle neck of users wishing to connect quickly builds up.
This is where connection pools come in.
The Programmer sets up a pool (say 50 connection) that are not attached to a
request at program startup time, this takes care of the time needed to create the
connections once the users start to connect as the program already has connections
hanging around ready for instant use. The other thing the programmer must do is
make sure that as soon as a connection has served it's purpose it is quickly put
back into the pool for other users to make use of.
JDBC 2.* compliant drivers will have a connection pool facility built in, but it
is not universally supported to the full JDBC2 spec yet. So you may have to do
your own!
>
> - What about thread safetyness and databases ?
All data that can be accessed by by multiple clients should be handled in a
transactional manner and care should be taken to make sure that updates or inserts
are "thread safe". The JDBC transactions help in this (note that the default is
auto commit) . The amount of locking of data that can be done is dependent on the
database. Some databases can handle single row locking where as others can only
lock up the whole table whilst data is being changed, I'm no expert in the
behavior of each database but I believe it is something that the Database
Administrator has to set up in his tuning.
Karl
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
