For some reason this thread is not repling to the list correctly.
I think that no matter what you do, if you want a persistent session you
need to send the data off server and the off server location, and this means
serialization and network traffic (unavoidable in all cases). As for
waiting for the db (which is just a file system in the basic case), this is
avoidable if you use a multicast system. The tradeoff is that each server
listening to the multicast must process the messages. In a crapy
implementation you get an n-to-the-n star network problem (you don't get n^n
connections but each server has to process the messages from the n other
servers).
The real answear the marc presented stands. There a billion possible
solutions and each one has different performance problems. What we in the
jboss group must do is define an interface to allow most (if not all)
implementaions.
Is there an interface for HttpSession persistence in the web container
layer?
-dain
> -----Original Message-----
> From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, September 01, 2001 2:50 PM
> To: Dain Sundstrom
> Subject: Re: [JBoss-dev] RE: Persistant HttpSession
>
>
> Just as IBM WebSphere is doing. But the problem is that
> you introduce the latency of the network and DB for a regular
> simple task.
> On the other side your fail-over and clustering is reduced
> to the one of the DB which can not become the bottleneck.
>
> Andy
>
> ----- Original Message -----
> From: "Dain Sundstrom" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, September 01, 2001 12:19 PM
> Subject: FW: [JBoss-dev] RE: Persistant HttpSession
>
>
> > I ment to send this to the list, but hit the wrong button.
> >
> > -----Original Message-----
> > From: Dain Sundstrom
> > Sent: Saturday, September 01, 2001 10:20 AM
> > To: 'Julian Gosnell'
> > Subject: RE: [JBoss-dev] RE: Persistant HttpSession
> >
> >
> > I saw a presentation at JavaOne from HP on thier highly scaleable
> > architecture and they were storing the http sessions into a
> db after each
> > request. The trick was they used a seperate database just
> for storing the
> > http session and this db was highly tuned for this type of
> use. With this
> > type of architecture you could tune the system to have a
> minimal impact
> from
> > the session storage. (As a side note if you know the
> structure of the http
> > session you could make is very fast).
> >
> > -dain
> >
> > > -----Original Message-----
> > > From: Julian Gosnell [mailto:[EMAIL PROTECTED]]
> > > Sent: Saturday, September 01, 2001 9:47 AM
> > > To: Bill Burke
> > > Cc: Kevin Duffey; Greg Wilkins;
> > > [EMAIL PROTECTED];
> > > [EMAIL PROTECTED]
> > > Subject: Re: [JBoss-dev] RE: Persistant HttpSession
> > >
> > >
> > >
> > > 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
> >
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
