Julian,
Again, I don't think a CMP Bean is a good idea. You'll be writing to the
database for every click on your website! This is just not scalable at all.
Your database will just get flooded with too many requests.
Bill
> -----Original Message-----
> From: jules [mailto:jules]On Behalf Of Julian Gosnell
> Sent: Saturday, September 01, 2001 6:05 AM
> To: Kevin Duffey
> Cc: Greg Wilkins; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Bill Burke
> Subject: Re: Persistant HttpSession
>
>
> 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
