Bill,
Looking at JavaGroups it sounds like it would possibly allow a good
mechanism for the HttpSession replication as well. My experience is mostly
with Orion so I have to take my example from what they do. They use
multicast for HttpSession fail-over, so when I clicked on that link and
started reading, it sounded like this may be a possible way for HttpSession
replication as well. What do you think? I read a few posts on the Orion
lists saying that using multicast can hinder network bandwidth but I wasn't
sure why this would be. If you set up x number of servers in a cluster to
listen on a specific port for replication messages, wouldn't that only use
one port? I'll have to read up more on multicast. I understand that it
broadcasts out to potentially x number of listeners, but just not sure about
the semantics of how it works.
> -----Original Message-----
> From: Bill Burke [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, September 01, 2001 10:11 AM
> To: marc fleury; Julian Gosnell
> Cc: Kevin Duffey; Greg Wilkins; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] RE: Persistant HttpSession
>
>
> Hey Julian/Marc,
>
> I hope didn't sound rude before. I was just pointing out what I
> think is a
> serious problem in using CMP.
>
> Julian, seriously, take a look at JavaGroups.DistributedHashtable
> http://www.javagroups.com It is really easy to use, and I think
> you'll find
> it really cool.
>
> Marc, the inVM thingy you were talking about before is a cluster SFSB. I
> agree that using EJB is a good abstration for this. I know jack
> squat about
> Message Driven Beans, but would that be a possibility as well?
>
> Regards,
>
> Bill
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of marc
> > fleury
> > Sent: Saturday, September 01, 2001 11:47 AM
> > To: Julian Gosnell; Bill Burke
> > Cc: Kevin Duffey; Greg Wilkins; [EMAIL PROTECTED];
> > [EMAIL PROTECTED]
> > Subject: RE: [JBoss-dev] RE: Persistant HttpSession
> >
> >
> > reading this reply I feel I should say what is on my mind
> > technologically-wise.
> >
> > It seems to me that you are asking for a EJB semantic and we
> are answering
> > with "persistence" issues. I think it is symptomatic and goes
> back to the
> > larger EJB discussions and particularly the Entity bashing that seems
> > popular these days.
> >
> > They are largely orthogonal issues. You can replace the
> > persistence engine
> > in JBoss. We allow for this, if you want A IN VM STORE WITH
> > REPLICATED JAVA
> > GROUPS as opposed to database access, WHAT PREVENTS US FROM
> DOING IT? (JMX
> > multinode batches of mods :)
> >
> > Julian is saying "I can get to work, manhana on this if I use the EJB
> > patterns". We as JBoss can get to work on this manhana if we
> isolate the
> > store work. Isolation. We have divided the work and the
> implementation of
> > the store is "irrelevant" from Julian's point of view.
> >
> > Bill, you are right, a database solution is probably the worst, but it
> > should not stop Julian from working until WE come up with a great store.
> > And what really gets me excited is the fact that EJB semantic is
> > natural and
> > the implementation is orthogonal... its the trend...
> >
> > Another example is the Jive forums... they use direct JDBC because the
> > persistence blabla and the replication bla bla bla... Same category of
> > problems the solution is in our camp.
> >
> > marcf
> >
> > |-----Original Message-----
> > |From: [EMAIL PROTECTED]
> > |[mailto:[EMAIL PROTECTED]]On Behalf Of
> > |Julian Gosnell
> > |Sent: Saturday, September 01, 2001 10: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
