You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tomcat.apache.org by Bip Thelin <bi...@razorfish.com> on 2001/03/26 23:56:44 UTC

JDBC-Session store

According to the STATUS.html(which doesn't seem to be up to date) no one seems
to have volunteered for the JDBC-Session store. If that is truly the case I
would like to volunteer for that part.

	Thanks, Bip

Re: JDBC-Session store

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Mon, 26 Mar 2001, Bip Thelin wrote:

> According to the STATUS.html(which doesn't seem to be up to date) no one seems
> to have volunteered for the JDBC-Session store. If that is truly the case I
> would like to volunteer for that part.
> 
> 	Thanks, Bip
> 

That is the case currently, so I have added you to the list.  Thanks for
volunteering!

Earlier, there was some discussion on refactoring the
Manager/Session/Store family of interfaces (and corresponding interface
classes) a little bit in the light of Kief's experience in adding
PersistentManager.  If you see things here that you think could be
improved, don't hesitate to suggest them.

Craig

Re: JDBC-Session store

Posted by Kief Morris <ki...@bitbull.com>.

Craig R. McClanahan typed the following on 07:05 PM 3/27/2001 -0800
>Kief, a while back (when the work on PersistentManager was going on), the
>need for a little refactoring work on Manager vs. StandardManager would be
>useful.  Have you thought any more about what we should do here?

Yes, in fact I was just working on this last week, playing around with
different ways of attacking this. Replacing dependencies on StandardManager,
StandardSession with dependencies on the Manager and Session interfaces
is relatively easy, with a few additions to the interfaces required. Another
problem I've been tackling is the architecture of the Manager hierarchy.

The problem is that there is code currently in StandardManager which
is needed by (and currently, duplicated in) PersistentManager, which
isn't good for maintenance.

StandardManager implements the Lifecycle interface and functionality
to expire sessions with a background thread. These are also used
by PersistentManager, with the session management code being
extended to handle swapping out idle sessions and similar tasks.

Currently, StandardManager also has persistence code, which is used
only to handle saving sessions on restarts. This code doesn't use the
Store system.

There are two approaches which seem like they would address this.
One solution is to make StandardManager and PersistentManager
subclasses of a common superclass with the functionality common
to both. Another is to make PersistentManager a subclass of 
StandardManager.

The first approach, making a hierarchy, appeals to me because it
makes it easier to experiment with alternative session managers.
DistributedManager would become a sibling to StandardManager
and PersistentManager. This solution requires either moving the
common functionality into the ManagerBase class, or creating
an intermediary abstract class. The second approach allows the
ManagerBase to remain a clean implementation of the Manager
interface, although it extends the hierarchy an extra level. 

The second approach doesn't appeal to me, mainly because it
seems likely to get a bit muddled over time.

Either way, another issue I see is that StandardManager, as long
as it supports persistence on restarts, is going to use a fair amount 
of the code from PersistentManager. This isn't necessarily a bad
thing, it will keep PersistentManager fairly simple. But I would
prefer to make it easy to develop a fully working Manager which
doesn't include any persistence whatsoever: either StandardManager
could have this (requiring users who want restart persistence to
use PersistentManager), or there could be a separate SimpleManager.

The first of the two solutions: making StandardManager and
PersistentManager siblings rather than one a subclass of the
other, seems likely to offer cleaner support for a StandardManager
without persistence and/or a SimpleManager.

Once the beta is tagged (this weekend?) I can start committing
some work on this.

Kief

RE: JDBC-Session store

Posted by Kief Morris <ki...@bitbull.com>.

Jone Lin typed the following on 03:35 PM 3/28/2001 -0800
>> No, we're much earlier in the development cycle than that - we haven't
>> implemented any distributed session support at all. The work we're doing 
>> on PersistentManager is groundwork for distributed sessions. This work 
>> is 90% finished, so after restructuring the relevant class 
>> hierarchy a bit 
>> and finishing PersistentManager, we'll be ready to tackle 
>> DistributedManager.
>
>What is schedule for these two nice managers?  Tomcat 4.1, maybe?

PersistentManager will be in the next beta, albeit in a slightly unfinished
form: it swaps out idle sessions,  but doesn't back up sessions. Whether
DistributedManager makes it into 4.1 depends on the relative development
pace of it vs. the whole Tomcat - i.e., if we finish it before the release, it'll
go in. Sounds like there's a fair amount of interest, so hopefully we'll have
plenty of hands to get it done. It might even make it into 4.0, since the
final release has to wait on the 2.3/1.2 spec release.

Kief

RE: JDBC-Session store

Posted by Jone Lin <jo...@openwave.com>.

> -----Original Message-----
> 
> Bip Thelin typed the following on 05:07 PM 3/27/2001 -0800
> >Kief Morris wrote:
> >> 
> >> Excellent! Let us know if you need any help.
> >
> >I will, BTW how is the work on distributed sessions coming along?
> >Is it possible to distribute sessions over x number of machines and
> >that if one goes down you could go to the other and happily continue
> >your session?
> 
> No, we're much earlier in the development cycle than that - we haven't
> implemented any distributed session support at all. The work we're doing 
> on PersistentManager is groundwork for distributed sessions. This work 
> is 90% finished, so after restructuring the relevant class 
> hierarchy a bit 
> and finishing PersistentManager, we'll be ready to tackle 
> DistributedManager.

What is schedule for these two nice managers?  Tomcat 4.1, maybe?

Re: JDBC-Session store

Posted by Kief Morris <ki...@bitbull.com>.

Bip Thelin typed the following on 05:07 PM 3/27/2001 -0800
>Kief Morris wrote:
>> 
>> Excellent! Let us know if you need any help.
>
>I will, BTW how is the work on distributed sessions coming along?
>Is it possible to distribute sessions over x number of machines and
>that if one goes down you could go to the other and happily continue
>your session?

No, we're much earlier in the development cycle than that - we haven't
implemented any distributed session support at all. The work we're doing 
on PersistentManager is groundwork for distributed sessions. This work 
is 90% finished, so after restructuring the relevant class hierarchy a bit 
and finishing PersistentManager, we'll be ready to tackle DistributedManager.

The session management system consists of implementations of the Manager, 
Session, and Store interfaces found in the root org.apache.catalina package. 
When we finish with it, we should have three implementations of Manager:
StandardManager, PersistentManager, and DistributedManager. Any Store
implementations should, in theory, be usable by either of the second two.
So your JDBCStore class, if it works with PersistentManager, should also
work with DistributedManager. The only difference is how the Store is used
by the Manager: PersistentManager only stores the sessions of one JVM,
while DistributedManager will store them for multiple JVMs.

In reality, I suspect that DistributedManager will require changes to the
current Store interface, so if you implement JDBCManager now and get
it working with PersistentManager, it may have to be updated as we
work on DistributedManager. If you want to help with DistributedManager,
doing JDBCStore might be a good first step for you to get your head
into the code. One issue I haven't figured out yet is how to configure
Catalina to use different Store implementations - PersistentManager
currently has FileStore hard-coded. If you want to dig into that it would
be a bonus. Catalina's configuration system is really slick.

There should be some messages of mine from a few months ago in
the archive for this list where I puzzled over some of the particular
issues of implementing DistributedManager which may or may not
be worth looking over.

Kief

Re: JDBC-Session store

Posted by Bip Thelin <bi...@razorfish.com>.

Kief Morris wrote:
> 
> Excellent! Let us know if you need any help.

I will, BTW how is the work on distributed sessions coming along?
Is it possible to distribute sessions over x number of machines and
that if one goes down you could go to the other and happily continue
your session?

	..bip

Re: JDBC-Session store

Posted by Bip Thelin <bi...@razorfish.com>.

"Craig R. McClanahan" wrote:
> 
> [...]
> Kief, a while back (when the work on PersistentManager was going on), the
> need for a little refactoring work on Manager vs. StandardManager would be
> useful.  Have you thought any more about what we should do here?

I couldn't find anything about how to add the PersistenManager in server.xml
or in the manuals, however, after backtracking the maillist I found a "patch"
by Kief that seems to have been forgotten, I'll cat it to the end of this mail.
Maybe it can find it's way into the server.xml after all.

	Cheers, Bip

------------------[ server.xml patch from Kief Morris ]------------------------

--- server.xml.orig	Sat Dec 16 20:03:29 2000
+++ server.xml	Fri Jan 12 22:01:04 2001
@@ -179,6 +179,53 @@
           <Ejb   name="ejb/EmplRecord" type="Entity"
                  home="com.wombat.empl.EmployeeRecordHome"
                remote="com.wombat.empl.EmployeeRecord"/>
+        <!-- 
+			PersistentManager
+			Uncomment the section below to test Persistent Sessions.
+			  
+			saveOnRestart: If true, all active sessions will be saved
+				to the Store when Catalina is shutdown, regardless of
+				other settings. All Sessions found in the Store will be 
+				loaded on startup. Sessions past their expiration are
+				ignored in both cases.
+			maxActiveSessions: If 0 or greater, having too many active 
+				sessions will result in some being swapped out. minIdleSwap
+				limits this. -1 means unlimited sessions are allowed.
+				0 means sessions will almost always be swapped out after
+				use - this will be noticeably slow for your users.
+			minIdleSwap: Sessions must be idle for at least this long
+				(in seconds) before they will be swapped out due to 
+				maxActiveSessions. This avoids thrashing when the site is 
+				highly active. -1 or 0 means there is no minimum - sessions
+				can be swapped out at any time.
+			maxIdleSwap: Sessions will be swapped out if idle for this
+				long (in seconds). If minIdleSwap is higher, then it will
+				override this. This isn't exact: it is checked periodically.
+				-1 means sessions won't be swapped out for this reason,
+				although they may be swapped out for maxActiveSessions.
+				If set to >= 0, guarantees that all sessions found in the
+				Store will be loaded on startup.
+			maxIdleBackup: Sessions will be backed up (saved to the Store,
+				but left in active memory) if idle for this long (in seconds), 
+				and all sessions found in the Store will be loaded on startup.
+				If set to -1 sessions will not be backed up, 0 means they
+				should be backed up shortly after being used.
+
+			To clear sessions from the Store, set maxActiveSessions, maxIdleSwap,
+			and minIdleBackup all to -1, saveOnRestart to false, then restart 
+			Catalina.
+		-->
+		<!--
+          <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.FileStore"/>
+          </Manager>
+		-->
           <Environment name="maxExemptions" type="java.lang.Integer"
                       value="15"/>
           <Parameter name="context.param.name" value="context.param.value"

Re: JDBC-Session store

Posted by Tim Tye <tt...@ticnet.com>.

In the Java world, varchar should support UNICODE characters, not 8-bit
bytes.
Yes, I know some data bases do not store UNICODE, but some (Oracle,
InstantDB etc) do.  The other problem with character, is character encoding,
when/if the encoding of the application does not match the native character
encoding of the table, a translation is performed, and the results are not
always reversible.
The correct type used to store serialized data is byte, or varbyte, or even
blob.
Remember, Java characters are unsigned sixteen bit numbers not eight bit
data elements (called char by 'C', 'C++' and many databases).

----- Original Message -----
From: Krishna R. Baddam <kb...@docutell.com>
To: <to...@jakarta.apache.org>; <bi...@razorfish.com>
Sent: Wednesday, March 28, 2001 7:25 PM
Subject: RE: JDBC-Session store


> Blob is a bad idea. Serialize the objects and store them as varchar. We
> implemented a home grown session store and the varchar route works lot
> better. I believe IBM's WebSphere session store also uses varchars.
>
> Krishna
>
> -----Original Message-----
> From: Bip Thelin [mailto:bip@razorfish.com]
> Sent: Wednesday, March 28, 2001 2:13 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: JDBC-Session store
>
>
> I've been looking at the FileStore implementation and you(Kief/Craig)
> basically
> store a java object in the textfile, using the same approach with a DB
> usually(?!)
> involves using a SQL3 capable RDBMS i.e. Oracle, since you probably want
to
> store
> the object as a Blob or might even work with a STRUCT. Anyway, I'm kind of
> reluctant
> to save objects in to a RDBMS and sort or "overriding" the native formats.
>
> Have anyone got any ideas on how to solve this in a good way? Preferably
so
> it would
> work with JDBC < 2.0 i.e., not use SQL3 datatypes. Otherwise I'll just go
> ahead and
> implement it as either a blob or a STRUCT whichever works out best.
>
> Thanks, Bip
>
>

RE: JDBC-Session store

Posted by "Krishna R. Baddam" <kb...@docutell.com>.

Blob is a bad idea. Serialize the objects and store them as varchar. We
implemented a home grown session store and the varchar route works lot
better. I believe IBM's WebSphere session store also uses varchars.

Krishna

-----Original Message-----
From: Bip Thelin [mailto:bip@razorfish.com]
Sent: Wednesday, March 28, 2001 2:13 AM
To: tomcat-dev@jakarta.apache.org
Subject: JDBC-Session store

I've been looking at the FileStore implementation and you(Kief/Craig)
basically
store a java object in the textfile, using the same approach with a DB
usually(?!)
involves using a SQL3 capable RDBMS i.e. Oracle, since you probably want to
store
the object as a Blob or might even work with a STRUCT. Anyway, I'm kind of
reluctant
to save objects in to a RDBMS and sort or "overriding" the native formats.

Have anyone got any ideas on how to solve this in a good way? Preferably so
it would
work with JDBC < 2.0 i.e., not use SQL3 datatypes. Otherwise I'll just go
ahead and
implement it as either a blob or a STRUCT whichever works out best.

	Thanks, Bip