Monitor what users are doing in an .net Application and trigger application functionality changes

I need some suggestions for how to implement a very basic mechanism that logs what multiple users are doing in an application. When another feature is running I then need to change the application, to restrict functionality.

Use Case Example User can normaly edit unpaid records. If the application then runs a Payrun process (Long), I need to then change parts of the application to restrict functionality for a short period of time (eg. Make existing unpaid records readonly).

Any suggestions on how I can do this in a .net application?

Architecture details

• VS 2008/2010,
• SQL Server 2005/2005,
• CSLA framework 3.8,
• VB.net
• Windows 2008 Web server 开发者_JS百科farm
• 900 + Users

The solution is an readonly extranet web reporting application and internal (firewall) data entry and data processing application (small single entry and large batch importing of data).

---

Normally we handle that in the database layer, since the individual applications on separate computers aren't directly aware of each other. The apps can check the database themselves prior to performing an operation or on a regular basis, or underlying stored procedures can manage the modality using some kind of simple table and locking for the semaphore.

On a non-distributed web application on a single server, you can handle this fairly easy with the Application object, since there really is one Application and it can monitor user activity fairly easily.

Let's assume you have just two modes and everything is handled in stored procs:

Mode where one user in doing some kind of POSTING operation and NORMAL mode. Let's assume that the operations in the POSTING operation are relatively simple, and for clarity we'll leave out the code which ensures no race conditions, and have all code inline instead of encapsulated into other SPs or functions:

CREATE PROCEDURE Post
AS
BEGIN
    UPDATE ModeControl
    SET Mode = 'POSTING'


    UPDATE Payments
    SET Whatever = whatever
    WHERE whatever

    UPDATE ModeControl
    SET Mode = 'NORMAL'
END

CREATE PROCEDURE IsPosting -- poll this in your app or before performing operations
AS
BEGIN
    IF EXISTS (SELECT * FROM ModeControl WHERE Model = 'POSTING')
        RETURN 1
    ELSE
        RETURN 0
END

CREATE PROCEDURE Normal1
AS
BEGIN
    -- Catches potential problems at database even though app shouldn't call in 'POSTING' more
    IF EXISTS (SELECT * FROM ModeControl WHERE Model = 'POSTING')
        RAISERROR...

    -- Perform Normal1 operations
END

CREATE PROCEDURE Normal2
AS
BEGIN
    IF EXISTS (SELECT * FROM ModeControl WHERE Model = 'POSTING')
        RAISERROR...

    -- Perform Normal2 operations
END

Obviously, if you have a full-blown data access layer and some framework bits, you can decorate your methods and use reflection to automatically categorize your methods and wrap them with checks about the unallowed modes to tie it into some kind of state-machine-type thing.