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]
