Let's also not exagerate here. Rewrite the complete system? Come on. It's a request interceptor that manages a webflow stack for each user. If anything, you're just adding a module with some minor GUI mods. Dr. Z apparently thinks that an application, once released, may not have subsequent release despite unexpected success of the application or the company in general. Push it off until it's needed.
This obviously has more to do with philosophy than it does with the original question. On 6/21/06, Andreas Winkler <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 But on the other hand if you had a client who wanted a cluster you could make one, but not if because of the underlying classes you had to rewrite the complete system. And as I experienced it, cluster/redundancy seem to get more and more important and there is no way around it. In an environment where every company has to be online 24/7 failure safety becomes a very crucial subject, especially for small companies. Monkeyden wrote: > I'd be surprised if that data was out there but logic tells me that > there > are far more small-med applications than there are med-large. Of > course the > underlying point is that every feature should be considered with it's > probability of being used. We do this all the time when we > determine scope > for each release. The most needed features typically get priority > on the > release schedule. > > The CTO of a company I worked for in 2001 wanted a web service based > platform (what came to be known as SOA) to use for our hosted > clients. We > defined the schemas, service locators, developed the web services, > EJBs and > a decoupled web layer, created a template engine for the request > documents > and many more utilities to simplify the XML work, etc, etc, etc. > When it > was done we had 20+ clients running on the platform and not a single > one was > on a cluster. An early full-feature release of an application > won't, and > shouldn't, attempt to solve all the problems which are out of > context for > the release. Make it a consideration? Absolutely, but the "what > if" part > of pragmatism is often taken too far, and to great and unecessary > expense. > > On 6/21/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> >> Monkeyden, I'd be careful with that assumption... clustering is pretty >> common in mid to large organizations based on my experience... I think >> any design that doesn't take it into consideration is a bad design. >> Even if your in a 5-person shop now running on a single server, do you >> want to deal with it 2 years down the road when all of a sudden your a >> big success, but your app won't scale to a clustered environment? >> >> I'd personally like to see some statistics that support either of our >> beliefs :) I'm not aware of any, although I'd bet they're out there. >> Even if it was true that the overwhelming majority of applications run >> on a single JVM, I would still contend it's a bad design practice >> to not >> plan for clustering... or at least, to do something that you know >> would >> be problematic in a cluster (and the difficulties can be very >> subtle, I >> can say that for sure from experience). >> >> Frank >> >> Monkeyden wrote: >> > I'm as forward-thinking as the next guy but let's not lose sight >> of the >> > fact >> > that, despite how pragmatic we engineers like to be, many more >> than half >> of >> > the applications developed and deployed are done so on a single >> JVM. An >> > overwhelming majority of those applications originally deployed on a >> single >> > JVM will never see a cluster. If you're grounded in reality, and >> not >> "what >> > if...", there is no sense in wasting time and resources developing >> > something >> > that will never be used. >> > >> > >> > On 6/21/06, Madhav Bhargava <[EMAIL PROTECTED]> wrote: >> >> >> >> For a single JVM this is a nice way to handle multipel submits. But >> >> then a >> >> solution should never be limited to one JVM and if it has >> problems when >> >> multiple JVM;s come into the picture then it should re-thought >> upon. I >> >> would >> >> rather not go for such a solution even though it is a good >> solution for >> a >> >> single JVM. >> >> >> >> On 6/21/06, Paul Benedict <[EMAIL PROTECTED]> wrote: >> >> > >> >> > Yes - of course it would. The solution is only for one JVM. >> You will >> >> need >> >> > another approach for a clustered environment. >> >> > >> >> > Madhav Bhargava <[EMAIL PROTECTED]> wrote: Consider a >> scenario of >> a >> >> > clustered environment where there are multiple >> >> > servers handling requests from an application. On each of these >> servers >> >> > session object will be replicated. This means that the same >> request >> can >> >> go >> >> > more than once. >> >> > >> >> > Shouldn't this solution fail then? >> >> > >> >> > ~madhav >> >> > >> >> > On 6/21/06, Paul Benedict >> >> > wrote: >> >> > > >> >> > > I've read many different techniques to stopping double >> submits, but >> >> one >> >> > > technique unfamiliar to me was described inside the Spring >> Framework. >> >> > > >> >> > > >> >> > > >> >> > >> >> >> http://www.springframework.org/docs/api/org/springframework/web/util/HttpSessionMutexListener.html >> >> >> >> >> > > >> >> > > It did not occur to me to lock the session to make sure that, >> >> within a >> >> > > user's dialog with the server, only one request from a session >> makes >> >> it >> >> > > through. Now read that carefully: not one user, but one request >> from >> >> one >> >> > > user. So 1000 different threads can be running, but locking the >> >> session >> >> > will >> >> > > ensure each is from a unique session. >> >> > > >> >> > > However, this class exists because some application servers >> do not >> >> > > guarantee that the same HttpSession object instance is re-used >> >> between >> >> > > requests. But the application server does need to guarantee the >> same >> >> > object >> >> > > instance with the session... So Spring provides this class >> (nothing >> >> but >> >> > a >> >> > > marker interface) if you want to head down this road. >> >> > > >> >> > > What do people think of locking the session via a session >> object? I >> >> like >> >> > > it, but I haven't implemented it -- but I want to use it if the >> >> feedback >> >> > is >> >> > > good. I have a few places in my application in which I want >> to make >> >> sure >> >> > the >> >> > > user progresses through my cattle chute in an orderly fashion. >> >> > > >> >> > > Paul >> >> > > >> >> > > >> >> > > --------------------------------- >> >> > > Do you Yahoo!? >> >> > > Everyone is raving about the all-new Yahoo! Mail Beta. >> >> > > >> >> > >> >> > >> >> > >> >> > -- >> >> > When I tell the truth, it is not for the sake of convincing those >> >> who do >> >> > not >> >> > know it, but for the sake of defending those that do >> >> > >> >> > >> >> > >> >> > >> >> > --------------------------------- >> >> > Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone >> calls. Great >> >> > rates starting at 1ยข/min. >> >> > >> >> >> >> >> >> >> >> -- >> >> When I tell the truth, it is not for the sake of convincing >> those who >> do >> >> not >> >> know it, but for the sake of defending those that do >> >> >> >> >> > >> >> -- >> Frank W. Zammetti >> Founder and Chief Software Architect >> Omnytex Technologies >> http://www.omnytex.com >> AIM: fzammetti >> Yahoo: fzammetti >> MSN: [EMAIL PROTECTED] >> Java Web Parts - >> http://javawebparts.sourceforge.net >> Supplying the wheel, so you don't have to reinvent it! >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEmZ3bCq2pT0ZuHYERArLjAJ9BXHhXmYnbDpTovAaezRE2OJYs0ACfZfjz Agvo5F2YyiXWbkSIK6iarC0= =v4G7 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
