Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 1263 invoked by uid 500); 16 Apr 2001 19:52:42 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: tomcat-dev@jakarta.apache.org Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 1249 invoked from network); 16 Apr 2001 19:52:41 -0000 Date: Mon, 16 Apr 2001 12:53:01 -0700 From: Bip Thelin Subject: Re: JDBCStore package for Tomcat 4.x To: tomcat-dev@jakarta.apache.org Reply-to: bip@razorfish.com Message-id: <3ADB4D9D.4E4183DC@razorfish.com> Organization: Razorfish MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <4.3.2.7.2.20010414103154.03408d98@pop3.demon.co.uk> X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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