You are right on all counts. The approaches to concurrency that you
mentioned are often missed by the current crop of "newbie" server
developers. These issues date back at least 20 years (as far I as
personally know!) since the early mainframes still had multiple users at the
same time.
A whole new generation grew up doing only PC development, and they are ill
prepared for the large scale, multi-user server world, though well suited
for the UI effort. The web has compounded this problem by the large number
of self-taught "web masters" who started off doing a little HTML, then more
HTML, then a little CGI, then javascript, then ASP/JSP, etc. These people
have learned some technology, but not how to design scalable, transactional
server-side systems. But that's okay, since I make a lot of money
architecting these systems then rewriting systems that my customers got
because "Bob took a course at the community college" and because
Frontpage/ColdFusion made it so easy <wink>.
> The issue is a standard multi-user problem - in the absence of a
> stateful locking scheme is the data I am writing consistent with what I
read
> ?
> There are many approaches:
> - re-read the record and compare each data item
> - use timestamps on access
> - track the keys of accessed items
> -differentiate between operations that are obviously read-only versus r/w
I've been quite fond of the timestamps scheme because there's utility in the
information provided by the timestamp (let's you know when it was last
updated!) and it makes checking for version changes easy and fast (a single,
usually numeric comparison). It also makes it easier on the client since
they only have to remember the "old" timestamp and not the entire old
"record." From an SQL standpoint you can enforce this by adding a simple
clause to the WHERE: AND old_timestamp = last_update_timestamp. If they
don't match, zero rows will be updated.
> Well, you are correct in stating that the developer must handle these
> actions.
> They won't go away by wishing it so...
> I contend however that the reason we use the browser is not because of its
> modeless paradigm but rather because of its ubiquity.
True, but being modeless (and connectionless) is the only reason why the web
even works. Almost no system today could handle 1 million concurrent TCP
connections, but it's possible to build systems that have 1 million
concurrent users, since each user is only connected and taking up valuable
resources to maintain the connection for a few seconds.
The real key is that the browser is simply not the best platform for
delivering interactive applications over the Internet. Many companies
realize this, but many more think that a browser is a good tool for doing
applications. They are generally wrong. The best Internet applications
these days are rarely browser-based (email, video, audio, stock tickers and
stock graphs, napster, instant messaging, chat...). The browser is best at
browsing, but it's a poor UI for a sophisticated application. Anybody who
has used a desktop application can easily see how lame a browser's UI is --
it's just a prettier version of 3270 terminals!
David
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
