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
