Jason Salas' WebLog

Come on, ever heard of a cache layer?

My point exactly - what if someone didn't know? Devs who don't how to code such a solution would lockup/lockout their users and destroy performance potentially app-wide (such as in cases where the main DB access is on the homepage...trust me, I've got experience in this), so is there an abstracted way to prevent inexperience from ruining an app?

One solution would be to artifically limit the number of events/sec. For example for an OnKeyUp type event, instead of doing the round-trip on every single key-press, you could kick off a timer to do in "n" seconds. Then, any subsequent key-ups would be ignored waiting for that timer to fire. When it fires "n" seconds later, you do the round-trip with the complete data.

So this way, even if you're typing really quickly, you'll only - at worst - be doing 1 roundtrip every "n" seconds. Also, "n" could easily be tuned (perhaps even in real-time!) so that if you're getting heavy load, you turn it up (meaning slightly slower response, but less round-trips), but if the load is light, you turn it down (meaning faster response but more round-trips).

I'm sure this could probably be done in a fairly generic way.

Can you really expect developers who don't know how to code "such solutions" (a cache isn't THAT complex) to write scalable systems - regardless of the technology being used.

@Udi Dahan:

I guess the other thing is that for though those of us who *are* capable of writing truely scalable apps, we may not always want to. We want it to be just "good enough" for our current user base, but still not bring our servers down if we happen to get slashdotted or whatever.

Obviously, if the app was meant for thousands of concurrent users, then something more advanced is required, but if we can provide for the 95% of situations where it's not *that* crucial, then so much the better!

Hi Udi,

The majority of code I see these days for tiered and data access in web-based apps isn't exactly picture-perfect in terms of providing for scalability and growth, although they certainly take expansion into consideration.

Access is not scaled to support heavy load... Use professional databases with connection pools and you won't have this problem.

Hi Bruno,

Yes about Access, and good point. *Most* experienced devs know this. BUT, and more importantly, I think this is a case of "hope for the best, expect the worst." Some people, whether by a lack of available resources, programmer ignorance, or just laziness are going to use Access. Much in the away we defensively design apps for users who will interact and misuse with them in a variety of ways, we can't assume developers will have access to, or write, perfect applications.

I was actually surprised when I learned that Microsoft was basing the storage mechanism for its membership container in ASP.NET v.2.0. But it makes absolute sense - optimally, all developers would use SQL Server or Oracle, but we can't guarantee that, so you need to account for backwards compatability, hence the need for the System.Data.OleDb namespace and its associated classes.

So the tools need to inherently be high-performance and scalable to an extent. That said, I don't really like Ajax from the standpoint of it being an app killer for people who whatever reason might use and connect to an Access database.

Someone else out there commented about an increased risk with Ajax-enabled pages and brute-force attacks: http://www.jamesdam.com/ajax_login/login.html

Why is this a problem compared with a form submit? I have an example online where I use a similar way to do authentication. I think it is more secure than a FORMS authentication if you use AJAX. Say, we submit username and password using AJAX, returning an authentication ticket and store it in the page as a JavaScript variable. It will not be displayed in the HTML code (caching) and will not be a cookie that may be a problem (not sure). I can create my own ticket, including IP address, browser agent, ... Where is the problem?

CIAO
Michael