struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Winkler <winkler.andr...@1visual.com>
Subject Re: Stopping Double Submits via mutex
Date Wed, 21 Jun 2006 19:28:28 GMT
-----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 <fzlists@omnytex.com> 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 <unmarshall@gmail.com> 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 <paul4christ79@yahoo.com> wrote:
>> >> >
>> >> > Yes - of course it would. The solution is only for one JVM.
>> You will
>> >> need
>> >> > another approach for a clustered environment.
>> >> >
>> >> > Madhav Bhargava <unmarshall@gmail.com> 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: fzammetti@hotmail.com
>> Java Web Parts -
>> http://javawebparts.sourceforge.net
>> Supplying the wheel, so you don't have to reinvent it!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>

-----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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message