Re: JDBCStore package for Tomcat 4.x
Kief Morris wrote:
[...]
I think this is a good way to go about it: it looks like the table name can be
configured
in the server.xml file. Probably the column names should also maintained as JDBCStore
properties for configurability.
Yes, that's why I wrote the last email to get some feedback on fields needed for the
table.
I'll implement it so it'll be configurable.
The table will need a column for the lastAccessedTime. And the ID column will need to
be something like CHAR, VARCHAR, or BYTE rather than an int.
Yes, a typo from me. I looked at your latest patches for Persistentmanager and the
Managerbase
and it looks good. However we should come up with some smart solution when working
with JDBCStore,
the processexpires() in PersistentManagerBase is looking for current sessions then
swaping them
in and checking if they're valid, if so continue else invalidate. This is fine for
FileStore but
with JDBCStore this causes each session to be retrieved over the network(or where the
RDBMS is located)
just to check if the session is valid. Maybe we could add a method to the Store
interface, i.e.
public boolean isSessionValid(String sessionId) {}.
What you would gain from this is that each Store is responsible for checking if
expired in
the way that's best for that particular Store, with JDBC you could do that in a single
select
statement without having to retrieve the data from the session(Assuming you save the
lastaccesstime in
the database, I'm currently working on that).
..bip
Re: JDBCStore package for Tomcat 4.x
On Mon, 16 Apr 2001, Bip Thelin wrote:
Kief Morris wrote:
[...]
I think this is a good way to go about it: it looks like the table name can be
configured
in the server.xml file. Probably the column names should also maintained as
JDBCStore
properties for configurability.
Yes, that's why I wrote the last email to get some feedback on fields needed for the
table.
I'll implement it so it'll be configurable.
The table will need a column for the lastAccessedTime. And the ID column will need
to
be something like CHAR, VARCHAR, or BYTE rather than an int.
Yes, a typo from me. I looked at your latest patches for Persistentmanager and the
Managerbase
and it looks good. However we should come up with some smart solution when working
with JDBCStore,
the processexpires() in PersistentManagerBase is looking for current sessions then
swaping them
in and checking if they're valid, if so continue else invalidate. This is fine for
FileStore but
with JDBCStore this causes each session to be retrieved over the network(or where
the RDBMS is located)
just to check if the session is valid. Maybe we could add a method to the Store
interface, i.e.
public boolean isSessionValid(String sessionId) {}.
What you would gain from this is that each Store is responsible for checking if
expired in
the way that's best for that particular Store, with JDBC you could do that in a
single select
statement without having to retrieve the data from the session(Assuming you save the
lastaccesstime in
the database, I'm currently working on that).
..bip
One of my original thoughts was along this line ... a Store should be
responsible for expiring its own swapped-out sessions. In practice, you
would have a background thread inside JDBCStore doing this for you. The
Store would also double check the current status while processing a
load().
Craig
Re: JDBCStore package for Tomcat 4.x
Bip Thelin typed the following on 12:53 PM 4/16/2001 -0700 the processexpires() in PersistentManagerBase is looking for current sessions then swaping them in and checking if they're valid, if so continue else invalidate. Hmm, it shouldn't be doing this, it should only be checking the sessions in memory. FileStore currently doesn't delete its expired sessions regularly since I stripped the background thread out. I don't think FileStore (or JDBCStore) need to check as often as the Manager does, but perhaps we should add the background thread code back in, but with a longer default interval. We may want to make a StoreBase class with the common code for this sort of thing, then extend it for FileStore and JDBCStore. Kief
Re: JDBCStore package for Tomcat 4.x
"Craig R. McClanahan" wrote: [...] One of my original thoughts was along this line ... a Store should be responsible for expiring its own swapped-out sessions. In practice, you would have a background thread inside JDBCStore doing this for you. The Store would also double check the current status while processing a load(). That's how I've implemented it right now, but that won't do it now when Kief has migrated it to the PersistentManagerBase. I think that it's good to abstract the thread/Lifecycle methods up to the Manager but maybe we should keep the proccessexpires method in the Store so each Store is responsible for checking expired sessions in it's own best way upon triggered from the reaper thread in the Manager. ..bip
Re: JDBCStore package for Tomcat 4.x
Bip Thelin typed the following on 03:57 PM 4/13/2001 -0700 - Would it be possible to parameterize the SQL statements used to access the database? The idea would be that we can adapt to different table and column names (like JDBCRealm does on the authentication side). ... I would like to propose that we save additional data in the database. The table would then look something like following: TABLE: [int ID] The ID for this session [boolean ISVALID] True if this session is valid [int MAXINACTIVE] The Max inactive attribute [Blob SESSION] The session object Then you could have a StoredProcedure if you want to that checks for timedout sessions and delete/invalidate them. I think this is a good way to go about it: it looks like the table name can be configured in the server.xml file. Probably the column names should also maintained as JDBCStore properties for configurability. The table will need a column for the lastAccessedTime. And the ID column will need to be something like CHAR, VARCHAR, or BYTE rather than an int. Kief
Re: JDBCStore package for Tomcat 4.x
"Craig R. McClanahan" wrote: [...] - Would it be possible to flesh out the rest of the JavaDoc comments? I would like us to maintain the high quality level of JavaDocs that Tomcat 4 is known for :-) Done. - Would it be possible to parameterize the SQL statements used to access the database? The idea would be that we can adapt to different table and column names (like JDBCRealm does on the authentication side). Attatched is a slightly refactored JDBCStore with a "stub implementation" of a Connection pooled implementation. However before I change to much regarding specifying columns for the table I want to have som input on the following things. As it is implemented now everything is saved as a Blob so if you wan't to check if the session is invalid or is expired you have to retrive all data and iterate through every blob and make them into a session and THEN see if they are valid or not. I would like to propose that we save additional data in the database. The table would then look something like following: TABLE: [int ID] The ID for this session [boolean ISVALID] True if this session is valid [int MAXINACTIVE] The Max inactive attribute [Blob SESSION] The session object Then you could have a StoredProcedure if you want to that checks for timedout sessions and delete/invalidate them. The StoreProcedure way of doing is of course not the default behavior. I can now check every session for validity in the select query without having to retrieve the data. Thoughts? ..bip /* * JDBCStore.java * $Header$ * $Revision$ * $Date$ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * "This product includes software developed by the *Apache Software Foundation (http://www.apache.org/)." *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software *Foundation" must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called "Apache" *nor may "Apache" appear in their names without prior written *permission of the Apache Group. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. * * [Additional notices, if required by prior licensing conditions] * */ package org.apache.catalina.session; import java.beans.PropertyChangeListener; import java.beans.PropertyChangeSupport; import java.io.InputStream; import java.io.OutputStream; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.io.InputStream; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.io.ObjectStreamClass; import java.sql.Connection; import java.sql.DriverManager; import java.sql.PreparedStatement; import java.sql.ResultSet; import java.sql.SQLException;
Re: JDBCStore package for Tomcat 4.x
On Sat, 7 Apr 2001, Bip Thelin wrote: Here's the JDBCStore implementation. To use it change your server.xml to something like: Manager className="org.apache.catalina.session.PersistentManager" debug="0" saveOnRestart="true" maxActiveSessions="1" minIdleSwap="-1" maxIdleSwap="1" maxIdleBackup="-1" Store className="org.apache.catalina.session.JDBCStore" driverName="com.merant.datadirect.jdbc.sqlserver.SQLServerDriver" sessionTable="tomcat$sessions" connectionURL="jdbc:mysql://localhost/authority?user=test;password=test" debug="99"/ /Manager You also have to create a table that has the fields id, session. And where id is a varchar field and session is a binary field, i.e. Blob. Sort of like: CREATE TABLE [dbo].[tomcat$sessions] ( [id] [varchar] (50) NOT NULL , [session] [binary] (1000) NULL ) However the SQL command varies from different RDBMS. Bip, A couple of quick notes: - Would it be possible to flesh out the rest of the JavaDoc comments? I would like us to maintain the high quality level of JavaDocs that Tomcat 4 is known for :-) - Would it be possible to parameterize the SQL statements used to access the database? The idea would be that we can adapt to different table and column names (like JDBCRealm does on the authentication side). ..bip Craig
Re: JDBCStore package for Tomcat 4.x
"Craig R. McClanahan" wrote: [...] A couple of quick notes: - Would it be possible to flesh out the rest of the JavaDoc comments? I would like us to maintain the high quality level of JavaDocs that Tomcat 4 is known for :-) Flesh out? As in enhance the comments? Yes that's possible, when I'm done I could write up a little Howto on how to use it and how it works, a'la JDBCRealm. - Would it be possible to parameterize the SQL statements used to access the database? The idea would be that we can adapt to different table and column names (like JDBCRealm does on the authentication side). Yes, and I acctually have some refactoring I would like to try out. Thanks for the comments and suggestions. ..bip
Re: JDBCStore package for Tomcat 4.x
On Tue, 10 Apr 2001, Bip Thelin wrote: "Craig R. McClanahan" wrote: [...] A couple of quick notes: - Would it be possible to flesh out the rest of the JavaDoc comments? I would like us to maintain the high quality level of JavaDocs that Tomcat 4 is known for :-) Flesh out? As in enhance the comments? Yes that's possible, when I'm done I could write up a little Howto on how to use it and how it works, a'la JDBCRealm. I was mostly concerned about the Javadocs that were missing on some of the methods. However, user docs are useful too. A good place for the details on configuration would be in the "Server Configuration" section of the Catalina documentation tree (directory "catalina/docs/config" in the source repository). We'll need to add a section for the Store directive similar to the others. - Would it be possible to parameterize the SQL statements used to access the database? The idea would be that we can adapt to different table and column names (like JDBCRealm does on the authentication side). Yes, and I acctually have some refactoring I would like to try out. Cool ... I look forward to seeing this. Thanks for the comments and suggestions. ..bip Craig
JDBCStore package for Tomcat 4.x
Here's the JDBCStore implementation. To use it change your server.xml to something
like:
Manager
className="org.apache.catalina.session.PersistentManager"
debug="0" saveOnRestart="true" maxActiveSessions="1"
minIdleSwap="-1" maxIdleSwap="1" maxIdleBackup="-1"
Store className="org.apache.catalina.session.JDBCStore"
driverName="com.merant.datadirect.jdbc.sqlserver.SQLServerDriver"
sessionTable="tomcat$sessions"
connectionURL="jdbc:mysql://localhost/authority?user=test;password=test"
debug="99"/
/Manager
You also have to create a table that has the fields id, session. And where id is a
varchar field
and session is a binary field, i.e. Blob. Sort of like:
CREATE TABLE [dbo].[tomcat$sessions] (
[id] [varchar] (50) NOT NULL ,
[session] [binary] (1000) NULL
)
However the SQL command varies from different RDBMS.
..bip
-
Index: LocalStrings.properties
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/LocalStrings.properties,v
retrieving revision 1.4
diff -u -r1.4 LocalStrings.properties
--- LocalStrings.properties 2001/02/03 20:36:20 1.4
+++ LocalStrings.properties 2001/04/08 01:57:06
@@ -5,6 +5,16 @@
fileStore.saving=Saving Session {0} to file {1}
fileStore.loading=Loading Session {0} from file {1}
fileStore.removing=Removing Session {0} at file {1}
+JDBCStore.alreadyStarted=JDBC Store has already been started
+JDBCStore.notStarted=JDBC Store has not yet been started
+JDBCStore.saving=Saving Session {0} to database {1}
+JDBCStore.loading=Loading Session {0} from database {1}
+JDBCStore.removing=Removing Session {0} at database {1}
+JDBCStore.SQLException=SQL Error {0}
+JDBCStore.checkConnectionDBClosed=The database connection is null or was found
to be closed. Trying to re-open it.
+JDBCStore.checkConnectionDBReOpenFail=The re-open on the database failed. The d
atabase could be down.
+JDBCStore.checkConnectionSQLException=A SQL exception occured {0}
+JDBCStore.checkConnectionClassNotFoundException=JDBC driver class not found {0}
managerBase.complete=Seeding of random number generator has been completed
managerBase.getting=Getting message digest component for algorithm {0}
managerBase.gotten=Completed getting message digest component
/*
* JDBCStore.java
* $Header$
* $Revision$
* $Date$
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* "This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
*Foundation" must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called "Apache"
*nor may "Apache" appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
