|
Posted by Webrickco on 07/25/07 18:39
On 25 jul, 18:52, Michael Fesser <neti...@gmx.de> wrote:
> .oO(Webrickco)
>
> >On Jul 25, 3:46 pm, Rik <luiheidsgoe...@hotmail.com> wrote:
>
> >This is a simple technical solution, that certainly would work for
> >most of the sites. What are the odds 2 different users open the page
> >at the exact same time? and if so, what would be the result? Miss one
> >count! In professional IT, you have to measure the odds against the
> >cost. Not everything is implementable regarding the costs. Consider
> >this a will-serve-in-most-case solution.
>
> The point is to understand what a race condition is, where it can happen
> and how to avoid it. This is important, especially in a shared environ-
> ment. In this particular case it's most likely just a little annoyance
> if it goes wrong. But in other cases a race condition might crash your
> application or even corrupt your data.
>
> So it's not about will-serve-in-most-cases, but about proper coding in
> general.
>
> Just my 2 cents
>
> Micha
Aggreed! but again this is an academic discussion. In professional
environment, you have to make decisions taking as parameters cost/time/
handling/odds. All these data together will tell you how to implement
the solution and most of the time it is NOT what is academically
right. There's not only one solution but many and you always choose
the one better adapted to the situation.
I believe and maintain that in the case of the web counter, and
poundering the relevance of the data showned, the solution i propose
would generate no error in 99% of sites in 99% of cases. You do not
spend tens of extra hours to develop the best solution if it covers
only the few cases that you are never sure they will happen, and for
those the accuracy of the data is irrelevant. Counter are just
indicators (that by the way are nowadays rarely used).
It's obvious that i could have developed a whole databased
transactionned solution in which never in a life time a case of
concurrency would have happened, just like Bpath do (i probably would
have had timeouts instead, due to overlocking, probably generating the
same amounts of errors). But it was not the purpose. Again, the
purpose was to show in a very simple way how to make a simple graphic
counter in PHP so that it can easily be changed and improved like i
say in my page. Many are made the exact same way in perl and cgi.
[Back to original message]
|