Suggestions to control concurrent users...

[pnp]

Hi all,
I've developed a win C# app that is actually database driven using SQL
server 2000. The idea is that only one application will be installed on
a server in a network and the program will be able to run at each client
machine by just double-clicking the application executable through a
network share. The program supports user logins.
What I want to do is find a secure way to control the number of
concurrent *users* using the application.


Any suggestions?

 

[Nicholas Paldino [.NET/C# MVP]]

pnp,

You could use transactions on the database level to do this, but I think
that is a bad idea. If you have to pass connections across objects, or use
other transactional resources, then doing that will not work.

Rather, I would recommend that you use the classes in the
System.EnterpriseServices namespace to create COM+ components. With these,
you can specify transaction boundaries which will allow resources to
register with COM+, and have COM+ control the transaction.

Or, you can use the classes in the System.Transactions namespace, if you
are using .NET 2.0.

Hope this helps.

 

[Alex Passos]

You can maintain statistical data about users logged in the system at anyone
time in the SQL Server database. When the app initializes the first thing
is to check that number against the maximum allowed, and if more gracefully
shutdown.

User starts app: UPDATE UserStats set usercount=usercount+1;
User shutsdown app (after a successful start): UPDATE UserStats set
usercount=usercount-1;

Alex

 

[Nicholas Paldino [.NET/C# MVP]]

Alex,

This will not solve the problem, though. It's not about how many users
are on the app, what matters is that they are all hitting the same data
source at the same time. If you have operations that require more than one
operation, then you need to wrap that in a transaction, so that the state of
the app doesn't become corrupted (where another user can see only a part of
a change that was made, and then acts upon it).

 

[Willy Denoyette [MVP]]

Hi all,
I've developed a win C# app that is actually database driven using SQL
server 2000. The idea is that only one application will be installed on a
server in a network and the program will be able to run at each client
machine by just double-clicking the application executable through a
network share. The program supports user logins.
What I want to do is find a secure way to control the number of concurrent
*users* using the application.


Any suggestions?

Why do you need to restrict the number of users? Is it a SQL performance or
a licence issue or something else.
I suppose you application is transaction safe (that is multi-user ready) so
that's no issue right?

Willy.

 

[Alex Passos]

He has only mentioned that he wants to control the number of concurrent
users on his app, not on SQL Server, but I completely understand your point.
More information is needed. from the OP.

Alex,

This will not solve the problem, though. It's not about how many users
are on the app, what matters is that they are all hitting the same data
source at the same time. If you have operations that require more than
one operation, then you need to wrap that in a transaction, so that the
state of the app doesn't become corrupted (where another user can see only
a part of a change that was made, and then acts upon it).


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

You can maintain statistical data about users logged in the system at
anyone time in the SQL Server database. When the app initializes the
first thing is to check that number against the maximum allowed, and if
more gracefully shutdown.

User starts app: UPDATE UserStats set usercount=usercount+1;
User shutsdown app (after a successful start): UPDATE UserStats set
usercount=usercount-1;

Alex

 

[pnp]

It is not an SQL server license issue, but my own applications license
issue.

The problem with storing data in the SQL server db is that if one of the
instances of the app fail to close correctly, my db will have the
wrong number of concurrent users, which can result in bigger problems
(one could eventualy not be able to log in).

But I would like a little more information on using COM+ to control the
users. Nicholas, can you please describe me a scenario in a little more
detail?

(I would rather not use the .NET 2.0 yet)

 

[Willy Denoyette [MVP]]

It is not an SQL server license issue, but my own applications license
issue.

The problem with storing data in the SQL server db is that if one of the
instances of the app fail to close correctly, my db will have the
wrong number of concurrent users, which can result in bigger problems (one
could eventualy not be able to log in).

But I would like a little more information on using COM+ to control the
users. Nicholas, can you please describe me a scenario in a little more
detail?

(I would rather not use the .NET 2.0 yet)

Ok, this is what I had guessed.
You need to track of the numer of instances running, well the best place to
do it is in the database. The problem with "vanishing applications", can be
solved by means of a stored procedure that each application has to execute
at regular intervals to update it's "state", a watch dog running in SQL
server could remove non updated entries at regular intervals.
Using COM+ for this is not an option IMO, as it's a single point of failure,
if the COM+ (or any other solution based on a centralized service) fails, it
would prevent your applications to be started while otherwise your SQL
server might be in perfect shape.

Willy.

 

[pnp]

Another problem could be that an advanced user could create a stored
procedure that deletes all the entries that are inserted in the db
continuously (or triggered by an insertion) so he could bypass my user
control scenario.