Here is what I suggest.
Greg, as Kevin suggests, selects the HttpSession class via property or
configuration parameter.
The current unclustered implementation is the default.
We put together a list of the features that such a class might need to offer -
I have the following at the moment:
Simple - no clustering support
Persistant - changes are remembered
Distributed - changes are replicated across the cluster (easier with
persistance)
Possible implementations I have so far:
Simple - already done
Persistant and Distributed - via e.g. a CMP bean, or a more complex
implementation which is a bit cleverer
Just Distributed - could use some underlying distribution technology,
javaspaces, http://www.javagroups.com/ - faster without persistance
I'm putting my hand up for the CMP bean stuff - unless I think of an easier
way.
Looks like Kevin is keen on a faster P&D solution
Bill might be interested in a JavaGroups Distributed implementation ???
How does that sound ?
Can anyone think of any more features that might be needed ?
Jules
Kevin Duffey wrote:
> I am not sure I would agree mostly because I personally like to design
> things right the first time over getting it out fast. But, I think we can do
> both. I haven't been able to look at the source yet, but I imagine if the
> container is configurable to specify what session manager to load (via a
> class name perhaps), we can then create one (or more) HttpSession
> implementations, each with their own special characteristics. In this way,
> its pluggable right from the getgo. What we can then do is turn Greg's
> existing HttpSession implementation into the "default" class to be loaded.
> >From there you and I can maybe both create a different implementation of
> HttpSession that is also pluggable so that Jetty will have 3 different
> versions. One that is non clusterable (for single JVM use and thus a bit
> more speed), and two that are for clustering.
>
> This is but one way we can maybe go about this. What do you two think?
>
> > -----Original Message-----
> > From: Julian Gosnell [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, August 31, 2001 5:59 AM
> > To: Greg Wilkins; Julian Gosnell
> > Cc: [EMAIL PROTECTED]
> > Subject: Persistant HttpSession
> >
> >
> >
> > > I don't know if it needs to be tied into EJBs?
> > > Depends on how you
> > > design your EJBs I guess.
> >
> > I think an initial naive implementation would probably
> > use EJBs, simply because I'm sitting in an EJB Server,
> > with all the necessary infrastructure for persistance
> > and distribution surrounding me.
> >
> > Only problem is, an EJB is a _STATIC_ wrapper around a
> > dynamic resource (i.e. you can stick new slots into a
> > table at run time, but not into a Java instance),
> > whereas an HttpSession is basically a HashTable, with
> > dynamic runtime structure. So all I will really be
> > doing is having an EJB with one instance data member
> > called HashTable, which contains the serialised (by
> > value) hastable.
> >
> > More complex, intelligent and faster implementations
> > could be thought up afterwards, but I think the
> > initial one should be as simple as possible and out
> > there as quickly as possible, and bug-free.
> >
> > Of course this puts certain constraints on what you
> > can put in your HttpSession - it has to be
> > serialisable - something Sun did not consider when
> > they came up with the HttpSession interface. This
> > means that moving a Servlet from a single node
> > deployment into a cluster may result in a change in
> > behaviour if it is not written according to certain
> > guidelines. I assume Sun must have published something
> > to this effect - I shall have to hunt it down.
> >
> > WebSphere implements one other strategy that gets this
> > done. The Master which dispatches the request to the
> > cluster can be configured to look for a session-id and
> > route requests with the same session-id to the same
> > node. This approach would allow you to deploy those
> > problem Servlets with the standard HttpSession object,
> > and no change in semantics - but then it's not really
> > clustering is it ... just double processing an HTTP
> > request instead of single processing it....
> >
> > Jules
> >
> >
> > ____________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
> > or your free @yahoo.ie address at http://mail.yahoo.ie
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
