On Fri, 26 Mar 1999, Alvin Lau wrote:
> ok, say i'm going to use a pool to hold my connections. initially the pool
> has only five connections. I assume that there are 50 students in a class.
> So they propably login at the same time. They are not all hit the
> button at the same second. say, 30 of them hit the button at the same
> second, then my pool for login will now holding 30 connections (I think
> connection's pool will automaticaly increase its size when it's
> nessecary). Am i correct? Also does a connection's pool will automatically
> reduce its size after some of the connection returned? Accounding to you,
> I need a connection's pool for all my servlets that access db. Say, my
> project has 10 servlet that will access db. So, in total, I have 300
> connections if the pool doesn't reduce its size automatically. I think 300
> connections are really too much. Do you have any solution for me.
[cut]
Hi.
Can't follow you.. I understand a situation with 30 users clicking the link
for the same servlet in the same second but... clicking all of them 10 links
each pointing different (or same) servlets, all that in the same second...
This can happen only if...well it hapens probably only if you use lots of
<IMG.. SRC=loginServlet> tags in each page...
Normally is enough to check user's identity only once during all
its session - at beginning, with a FORM-based login screen
Even if that terrific scenario happens, pools usually silently close unused
connections in order to spare RAM and/or licenses. At least most of them.
So normally you can ignore that issue.
But I keep my opinion that you don't need a pool. Just one dedicated
connection in your servlet should be enough, something like:
static Connection uPassConnection = null;
// Call this before using connection
static checkInitConnection() {
if(
(uPassConnection != null) &&
!uPassConnection.isClosed()
) return uPassConnection; // if connection is OK no need to initialise
it...
// Here initialise the connection from config parameters...
}
public static boolean
checkIdPass(String userId, String userPass) {
synchronised(uPassConnection) {
checkInitConnection();
... get statement from connection..., resultset
querry = "SELECT COUNT(*) FROM userTable WHERE userId='" +
userId + "' AND userPass = '" + userPass + "' ;" ;
....
if(retrieved an 0) return false;
else return true;
}
}
----------------------------------
You'll be able to call checkIdPass() at least ten times each second.
It reuses the connection as a pool does..
If simple key lookup isnt fast enough to be used once at beginning of
a new HttpSession..
Reusing a PreparedStatement instead of Connection will give even faster
execution.
If necessary you'll be able to check an user's pass from all other
servlets by calling the static LoginServlet.checkIdPass(userId, pass);
with no visible performance penalties..
Getting 20 concurent users logging in within the same second
is difficult even on heavely loaded servers... a rare event
when... what? they'll wait 2-3 seconds more..
Cezar
P.S: You'll need to catch some SQLExceptions in previous code..
>
> One of the solutions(I think) is that: i write a servlet that used to hold
> all the connections in my project. when other servlets want to get a
> connection, they just get it from my connection's servlet. Is it possible?
> How fast do the servlet commumicate with each others?
Fast. They are simple objects or classes sharing the same Java
virtual machine, calling each other's methods...
>
> alvin
>
>
> On Thu, 25 Mar 1999, Scott Neufeld wrote:
>
> > You answered your own question -- multiple simultaneous queries requires multiple
> > simultaneous connections. So, you can create a new connection each time, or use a
> > connection pool. The first is inefficient because it is expensive to open and
> > close/kill connections to a database. The second is efficient because it maintains
> > open connections to the database.
> >
> > Go to www.javaexchange.com for more info on this.
> >
> > Boy, it's Connection Pool day here on the servlet-interest listserv!
> >
> >
> > Alvin Lau wrote:
> >
> > > Thank you for your information about transaction.
> > >
> > > I used only one connection (put it in init()and use it in doPost()). I
> > > didn't test my code seriously ( it seem to be working well). It's not easy
> > > to debug. What do you mean by "multiple simultaneous connection"? also a
> > > question want to ask you, can a connection handle mutiple simultaneous
> > > query correctly? What will go wrong if I do it in my way?
> > >
> > > I'm not with my computer these two day. I think i will send my codes here,
> > > and may be you (or someone) can give me some +ve advice.
> > >
> > > alvin, lau
> > >
> > > On Thu, 25 Mar 1999, Scott Neufeld wrote:
> > >
> > > > Do you create a new connection each time a user tries to login? Or do you use
> > > > the same one each time? The first is extremely inefficient, and the second one
> > > > will not allow multiple simultaneous connections, and this is also extremely
> > > > inefficient.
> > > >
> > > > It is not just for transactions, it is for maintaining open database
> > > > connections that can be used as needed by one or more servlets (or helper
> > > > classes).
> > > >
> > > > Alvin Lau wrote:
> > > >
> > > > > I'm building a marketing's games, and I made a login's servlet a few weeks
> > > > > ago. What I did is that, when a user login in, first I check the user pw
> > > > > and id, and if I find a record in my db, then I create a new user's obj
> > > > > and put it in the session.
> > > > >
> > > > > I really don't understand why you need a connection pool. For me you need
> > > > > a connection pool only if you have to do transaction. Am i correct?
> > > > >
> > > > > If you want to see my codes, just let me know.. :-)
> > > > >
> > > > > alvin lau
> > > > >
> > > > > ___________________________________________________________________________
> > > > > 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
> > > >
> > > > ___________________________________________________________________________
> > > > 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
> > > >
> > >
> > > ___________________________________________________________________________
> > > 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
> >
> > ___________________________________________________________________________
> > 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
> >
>
> ___________________________________________________________________________
> 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
>
Cezar Totth email: [EMAIL PROTECTED]
Fax: (401) 220 33 95
Genesys Software Romania Phone: (401) 638 49 44
Stefan Furtuna 169, sect.6
cod 77171, Bucharest
Romania
___________________________________________________________________________
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
