-----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]
