Suggestions to control concurrent users...

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?

re: Suggestions to control concurrent users...

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.


--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard.caspershouse.com

"pnp" <pnp.@.softlab.ntua.gr> wrote in message
news:e4KSFT6OFHA.3156@TK2MSFTNGP15.phx.gbl...[color=blue]
> 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?[/color]

re: Suggestions to control concurrent users...

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" <pnp.@.softlab.ntua.gr> wrote in message
news:e4KSFT6OFHA.3156@TK2MSFTNGP15.phx.gbl...[color=blue]
> 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?[/color]

re: Suggestions to control concurrent users...

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]
- mvp@spam.guard.caspershouse.com

"Alex Passos" <bz@netmerlin.nospam.com> wrote in message
news:ekMF1b6OFHA.3156@TK2MSFTNGP15.phx.gbl...[color=blue]
> 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" <pnp.@.softlab.ntua.gr> wrote in message
> news:e4KSFT6OFHA.3156@TK2MSFTNGP15.phx.gbl...[color=green]
>> 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?[/color]
>
>[/color]

re: Suggestions to control concurrent users...

"pnp" <pnp.@.softlab.ntua.gr> wrote in message
news:e4KSFT6OFHA.3156@TK2MSFTNGP15.phx.gbl...[color=blue]
> 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?[/color]

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.

re: Suggestions to control concurrent users...

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.

"Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> wrote in
message news:u8kX6e6OFHA.3788@tk2msftngp13.phx.gbl...[color=blue]
> 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]
> - mvp@spam.guard.caspershouse.com
>
> "Alex Passos" <bz@netmerlin.nospam.com> wrote in message
> news:ekMF1b6OFHA.3156@TK2MSFTNGP15.phx.gbl...[color=green]
>> 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" <pnp.@.softlab.ntua.gr> wrote in message
>> news:e4KSFT6OFHA.3156@TK2MSFTNGP15.phx.gbl...[color=darkred]
>>> 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?[/color]
>>
>>[/color]
>
>[/color]

re: Suggestions to control concurrent users...

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] wrote:[color=blue]
> "pnp" <pnp.@.softlab.ntua.gr> wrote in message
> news:e4KSFT6OFHA.3156@TK2MSFTNGP15.phx.gbl...
>[color=green]
>>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?[/color]
>
>
> 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.
>
>
>
>[/color]

re: Suggestions to control concurrent users...

"pnp" <pnp.@.softlab.ntua.gr> wrote in message
news:u4aL7EBPFHA.3908@TK2MSFTNGP10.phx.gbl...[color=blue]
> 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)
>[/color]


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.

re: Suggestions to control concurrent users...

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.

Willy Denoyette [MVP] wrote:[color=blue]
> "pnp" <pnp.@.softlab.ntua.gr> wrote in message
> news:u4aL7EBPFHA.3908@TK2MSFTNGP10.phx.gbl...
>[color=green]
>>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)
>>[/color]
>
>
>
> 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.
>
>
>[/color]