By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,208 Members | 1,592 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,208 IT Pros & Developers. It's quick & easy.

Suggestions to control concurrent users...

P: n/a
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?
Nov 17 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
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]
- mv*@spam.guard.caspershouse.com

"pnp" <pnp.@.softlab.ntua.gr> wrote in message
news:e4**************@TK2MSFTNGP15.phx.gbl...
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?

Nov 17 '05 #2

P: n/a
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:e4**************@TK2MSFTNGP15.phx.gbl...
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?

Nov 17 '05 #3

P: n/a
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]
- mv*@spam.guard.caspershouse.com

"Alex Passos" <bz@netmerlin.nospam.com> wrote in message
news:ek**************@TK2MSFTNGP15.phx.gbl...
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:e4**************@TK2MSFTNGP15.phx.gbl...
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?


Nov 17 '05 #4

P: n/a

"pnp" <pnp.@.softlab.ntua.gr> wrote in message
news:e4**************@TK2MSFTNGP15.phx.gbl...
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.


Nov 17 '05 #5

P: n/a
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]" <mv*@spam.guard.caspershouse.com> wrote in
message news:u8**************@tk2msftngp13.phx.gbl...
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]
- mv*@spam.guard.caspershouse.com

"Alex Passos" <bz@netmerlin.nospam.com> wrote in message
news:ek**************@TK2MSFTNGP15.phx.gbl...
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:e4**************@TK2MSFTNGP15.phx.gbl...
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?



Nov 17 '05 #6

P: n/a
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] wrote:
"pnp" <pnp.@.softlab.ntua.gr> wrote in message
news:e4**************@TK2MSFTNGP15.phx.gbl...
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.

Nov 17 '05 #7

P: n/a

"pnp" <pnp.@.softlab.ntua.gr> wrote in message
news:u4**************@TK2MSFTNGP10.phx.gbl...
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.

Nov 17 '05 #8

P: n/a
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.

Willy Denoyette [MVP] wrote:
"pnp" <pnp.@.softlab.ntua.gr> wrote in message
news:u4**************@TK2MSFTNGP10.phx.gbl...
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.

Nov 17 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.