I understand what you are saying, Bill.
I am not proposing this as an enterprise level solution.
I am proposing it as a full-featured (distributed/persistant) but trivial
implementation.
This means we can get it done quickly. More quickly than perhaps Kevin might
get his solution implemented or a JavaGroups solution might get done.
Because it is very simple, it is unlikely to be buggy.
Once we have a rock-solid implementation, we can turn around and look at better
solutions. If you want to write a JavaGroups solution you are very welcome to.
I don't see anything on your website about persistance, which I assume is the
reason why your proposed solution would be faster. However I would be surprised
if it was actually simpler and required less additional infrastructure (over
and above JBoss, because that is the perspective from which I am working) than
a CMP solution.
Besides DB access will only be necessary if a Servlet/JSP needs to read/write
state. This is not the case with every click on a website. If the Servlet is
reading/writing state, then is is probably accessing EJBs too (JBoss
perspective again), so the cost of one more access may not be so unpalatable.
I fully expect CMP to be the slowest solution, but I am not going to launch
myself into a new problem space without a little recce trip and that is what my
CMP HttpSession (If I actually write it) was intended to be - sorry if this was
not made clear.
Distribution may actually be a good enough solution, without persistance,
provided that as new nodes come up they can update themselves simply from the
rest of the cluster. Provided that the whole cluster does not go down at once.
With 2 or 3 solutions to the problem we will all be in a better situation to
choose the one that best suits us. It's horses for courses.
Cheers,
Jules
Bill Burke wrote:
> 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
_________________________________________________________
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
