possible JDBCRealm bug?

[To...@putnam.com]

org.apache.tomcat.aaa.JDBCRealm opens a database connection and never
closes the connection.

Would not a more correct behaviour be to open/close the connection
before/after verifying credentials?

When the connection is kept open, the corresponding database is held up.
For example, when using postgres, one cannot shutdown and restart the db
server without first
shutting down tomcat.

thought? opinions?

-Tony Chao


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: possible JDBCRealm bug?

["Craig R. McClanahan" <cr...@apache.org>]

On Thu, 1 Aug 2002 Tony_Chao@putnam.com wrote:

> Date: Thu, 1 Aug 2002 17:09:11 -0400
> From: Tony_Chao@putnam.com
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: tomcat-dev@jakarta.apache.org
> Subject: possible JDBCRealm bug?
>
> org.apache.tomcat.aaa.JDBCRealm opens a database connection and never
> closes the connection.
>
> Would not a more correct behaviour be to open/close the connection
> before/after verifying credentials?
>

Doing this would make authentication horrendously slow on many databases,
where establishing a connection can take many seconds.  A better approach
would be to use a connection pool (because you could then support multiple
simultaneous authenications) -- but that doesn't solve your "open
connections" issue.

> When the connection is kept open, the corresponding database is held up.
> For example, when using postgres, one cannot shutdown and restart the db
> server without first
> shutting down tomcat.
>
> thought? opinions?
>

IMHO this is going to be the case for any web application that uses a
connection pool anyway.  However, one thing that many connection pools let
you do is define a "validation query" or "ping query" that must succeed
before the connection is returned to the user -- this would cause all the
bad connections in the pool to get thrown away without impacting the app
(other than the longer than usual time to establish a new replacement
connection).

Modifying JDBCRealm to use such a connection pool would seem like the best
course of action.

> -Tony Chao
>

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>