Comments on: Asynchronous, High-Performance Login for Web Farms

By: udidahan

udidahan — Tue, 12 May 2009 20:44:52 +0000

Scott,

All you need to do is define a public property on your message handler of the type IBus, and it’ll work.

Feel free to ask these questions on the discussion group as well:

http://tech.groups.yahoo.com/group/nservicebus/messages

By: Scott Johnson

Scott Johnson — Mon, 11 May 2009 18:01:43 +0000

I am evaluating nServiceBus for an upcoming project, and I need the functionality described in this article of the BaseMessageHandler. Unfortunately, I cannot locate this reference anywhere in the 1.9 RTM I have installed. My events are currently inheriting IMessageHandler, but I need to use this.Bus.Reply(), and I can’t. Have I missed something?

By: udidahan

udidahan — Mon, 04 May 2009 08:15:29 +0000

Jørn,

Since the app server actually handles the process of registering the user, the user doesn’t receive an OK until they go through the app server (and they confirm their email address).

The purpose of the web server cache is primarily to offload the reads from the database giving us near linear scalability in adding web servers for the login function. While it also serves us for first-level conflict detection, it isn’t the authoritative source of information.

Does that answer your question?

By: Jørn Wildt

Jørn Wildt — Mon, 04 May 2009 07:54:34 +0000

Back to the question about registering twice (unique constraints on email for instance): how would the GUI handle this situation?

Scenario:

1) User registers new name/email. This account does not exist on the webserver, so the user gets the immediate answer “Ok”.

2) The register-new-user message arrives in the app server where a clash is detected.

How is the user informed of this cancellation of his account?

Thanks, Jørn

By: Messaging v Enterprise aplikáciách. NServiceBus. - Tomáš - DevBlog

Messaging v Enterprise aplikáciách. NServiceBus. - Tomáš - DevBlog — Tue, 03 Mar 2009 09:17:13 +0000

[...] DDD) pridáva praktické(nielen design) argumenty a ilustruje ich na user logon scenári – Asynchronous, High-Performance Login for Web Farms. Udi ďalej uzatvára diskusiu o zmysle messagingu v aplikáciach medzi Ayendem a Gregom Youngom [...]

By: Messaging ROI

Messaging ROI — Sun, 22 Feb 2009 10:13:10 +0000

[...] post, he follows the design I described a while back on using messaging for user management and login for a high-scale web scenario. In his comments, he agrees with the above stating: “I certainly think that a similar [...]

By: udidahan

udidahan — Fri, 19 Dec 2008 20:07:16 +0000

Jai,

Here’s some:

If you can ensure that the call will be local, you can often make it synchronous.

If you suspect that a call will be remote, you should prefer to make it asynchronous / non-blocking.

By: Jai Lalwani

Jai Lalwani — Fri, 19 Dec 2008 06:33:26 +0000

Udi,
Do you’ve any such guidelines, when to and not to make things asynchronous.

Regards,
Jai

By: udidahan

udidahan — Wed, 29 Oct 2008 13:27:38 +0000

Daniel #4,

Foreign keys and unique constraints are still enforced in the DB. The web server, by having a copy of emails locally, can avoid calling through to the DB for user registrations which are clearly invalid. Still, the web server doesn’t add users on its own volition, but submits a request through to the DB for that.

The point of this web tier caching is to reduce load on the DB, not to replace it entirely.

There are cases where “things can’t be made asynchronous”, but less than you might think. I do have guidelines around them, but they fill up a 5-day course and are very much tied to understanding the specifics of your business domain.

Hope that helps.

By: Daniel

Daniel — Tue, 28 Oct 2008 15:14:03 +0000

I’m a different Daniel from #2, but have a related question. I’m still trying to get my head around this concept and have two questions:

-How are foreign keys and unique constraints handled in this setup? For example, if there is a unique constraint on email in the database, but the web server allowed a user to register the same email twice. Is it expected that all such constraints should be enforced in the service in addition to the database?

-Are there, in fact, cases where “things can’t be made asynchronous”? When designing a system, do you have any guidelines for when to/not to use nServiceBus and event-driven design?

By: udidahan

udidahan — Sun, 29 Jun 2008 07:59:21 +0000

Daniel,

Here’s how to do it:

On each invalid login, send an InvalidLoginMessage.

The “service-side” handles that message and writes the number of attempts. If the number of attempts is greater than N, publish an AccountLockedMessage.

When web servers get that notification, they mark the account as locked preventing further attempts to login.

This solution leaves a window of time open (probably less than a second) where a user may be able to attempt to login more than N times. On the other hand, the solution is much more scalable than regular locking based solutions.

The tradeoff should be made at the system level, and not the feature level. I think that it’s more than acceptable.

By: Daniel

Daniel — Fri, 27 Jun 2008 14:33:41 +0000

What if you need to lock the account after three invalid attempts to login? You can still refuse invalid usernames on web server, but you’ll need to synchronize the number of invalid logins (valid username, invalid password) between all web servers after each invalid login, and/or write it to the database. I think it’s quite common feature.

By: TechEd USA 2008

TechEd USA 2008 — Sat, 31 May 2008 10:56:37 +0000

[...] performance and scalable web applications based on the principles I outlined in my previous post Asynchronous, High Performance Login for Web Farms. I’ll also be giving a more interactive session on How to Avoid a Failed SOA, and coming in [...]