Managing multiple users

[Dom]

Several users can use my application at the same time, each one
working on a different laptop, of course. But there are sections of
the code that must be managed -- that is, I can't have two people
executing this code at the same time, but instead each user closes a
"gate" that keeps other users out, then opens the gate, allowing only
one in, who then closes the gate, and so on.

Usually I accomplish this by using a SQL Table, and a
ExecuteNonQueryTransaction and ExecuteNonQueryTransactionContinued
methods in the SqlClient namespace. This works perfectly, and I
believe I discovered this trick from this group.

But in my recent program, I can't use the SQL table. I don't want to
bother explaining why, since that isn't really relevant, but I for
various reasons I can't.

Is there another way to do the same thing?

 

[zach]

Several users can use my application at the same time, each one
working on a different laptop, of course. But there are sections of
the code that must be managed -- that is, I can't have two people
executing this code at the same time, but instead each user closes a
"gate" that keeps other users out, then opens the gate, allowing only
one in, who then closes the gate, and so on.

Usually I accomplish this by using a SQL Table, and a
ExecuteNonQueryTransaction and ExecuteNonQueryTransactionContinued
methods in the SqlClient namespace. This works perfectly, and I
believe I discovered this trick from this group.

But in my recent program, I can't use the SQL table. I don't want to
bother explaining why, since that isn't really relevant, but I for
various reasons I can't.

Is there another way to do the same thing?

I do that sort of thing with a static bool. Works fine.

 

[zach]

You look up design patterns and know the basics of object oriented
programming

 

[Dom]

Well you a-hole,  are you name calling? You are completely out of
line here.


Opinions are a time a dozen, and everyone has an opinion. Do I care
about your opinion?

I don't need your lip service. Because you say something does it make
it right?

You need to keep your lip service to yourself.

I know your about to go off here with some worthless babble you seem
to be the lunatic type. But can you keep it to yourself, because I
don't want to know what you think?

Please keep in mind that I am talking about different users on
different laptops, running (of course) different instances of the
application. This is not a single user on a single laptop running
multiple applications that need to be coordinated.

 

[Boreas]

Please keep in mind that I am talking about different users on
different laptops, running (of course) different instances of the
application. This is not a single user on a single laptop running
multiple applications that need to be coordinated.

Is your problem statement as follows: Laptops a, b, and c each have an
application AP installed. APa, APb and APc make use of an application
installed on laptop D. They cannot all use that application at the same
time. Then set up a flag in a file on D, and test to see whether the flag is
down. You could even do FIFO queuing that way.

 

[Arne Vajhøj]

Please keep in mind that I am talking about different users on
different laptops, running (of course) different instances of the
application. This is not a single user on a single laptop running
multiple applications that need to be coordinated.

Which you clearly stated in your original question.

Which makes the two arguing persons above look rather
funny.

Arne

 

[Arne Vajhøj]

Several users can use my application at the same time, each one
working on a different laptop, of course. But there are sections of
the code that must be managed -- that is, I can't have two people
executing this code at the same time, but instead each user closes a
"gate" that keeps other users out, then opens the gate, allowing only
one in, who then closes the gate, and so on.

Usually I accomplish this by using a SQL Table, and a
ExecuteNonQueryTransaction and ExecuteNonQueryTransactionContinued
methods in the SqlClient namespace. This works perfectly, and I
believe I discovered this trick from this group.

But in my recent program, I can't use the SQL table. I don't want to
bother explaining why, since that isn't really relevant, but I for
various reasons I can't.

Is there another way to do the same thing?

Synchronization requires something shared.

database (even though your app does not use database for
what it has to do, then you can still use database for
synchronization)

file on a file share

something in memory of a server app being called by the
app instance (remoting, SOAP/HTTP, plain sockets)

some replicated memory over the network typical
multicast style between all app instances with
some locking protocol - also called a
distributed lock manager

I am lazy so I would go for one of the two first
solutions.

The last one is the most sophisticated and the
one used in Oracle RAC, OpenVMS clustering etc..

Arne

 

[Arne Vajhøj]

I am not arguing about anything. I don't appreciate some little clown in
Pampers tying to tell me something with his smart mouth.

If you in a public forum suggest that people should learn the
basics of OOP and clearly demonstrate that you have not even
been able to read and understand the question asked, then expect
people to tell you something.

And on your
second post, you have not said anymore than I already told him.

You need glasses.

Arne

 

[Arne Vajhøj]

You don't even know what you are talking about. I gave the op a
singleton object patteren. An object can be instancated on the backend
solution to control the single usage of the application by clients. I
mentioned OOP(s) due C# .Net is a OOP language. Anyone doing SOA
development would know exactly what I was talking about.

It's not my fault that you cannot think outside the desktop box.

Your assumption about my skill sets are both wrong and irrelevant.

Amazing that someone who thinks my interest in SOA or desktop
apps have any relevance for whether my second post contains
new stuff has the skills necessary to post to usenet.

Arne

 

[Boreas]

. . . I don't appreciate some little clown
in Pampers tying to tell me something with his smart mouth. . . .

Happy with the opportunity to press the snotty button?

 

[Dom]

I am not taking any crap from anyone. I  was minding my own business.
I don't need the lip service.

Thanks, Arne. I think I'll go with the file on a file share.

Dom

 

[Jeff Johnson]

It's just something else you will have to deal with when things go wrong
and all users are locked out.

True, but given the level of synchronization the OP appears to be looking
for, SOMEWHERE in this system there's going to be a single point of failure.
In this case it's a file server. Personally, I like the odds on that. I've
found file servers to be more reliable than just about any other type of
server.

 

[Jeff Johnson]

I am talking about the software blew and it did not make it back to unlock
something on a file share, locking out all users until the unlock is
removed. I myself would avoid programmimg this in a multiple user
scenario.

HAHAHA, you just described Microsoft Access!!

(Note: I'm not an Access hater, in fact I'm rather fond of it, but this was
one of the biggest problems with trying to use it as a multi-user DB.)

 

[Boreas]

Thanks, Arne. I think I'll go with the file on a file share.

That is what I suggested to you. (Then also use a loop to stop collisions
reading the file contents by different users.)

 

[Arne Vajhøj]

I am not taking any crap from anyone. I was minding my own business.

No you were not.

You chose to participate in a public forum.

You suggested that the OP studied basic OOP even though you in the
rest of the reply demonstrated inability to understand very simple
problem description.

And then you continued with name calling after someone pointed
out that you were being rude.

That is about as far from minding your own business as possible.

Arne

 

[Arne Vajhøj]

I am talking about the software blew and it did not make it back to
unlock something on a file share, locking out all users until the unlock
is removed. I myself would avoid programmimg this in a multiple user
scenario.

There are better ways to do this. One would be to use a WCF service exe
over TCP/IP.

The problem of how to handle a client that does not unlock is
the same no matter where the global lock is kept.

The OP will need to decide on manual force unlock or timeout after
X seconds.

DB, File, WCF or DLM does not matter.

Arne

 

[Arne Vajhøj]

You are not a monitor of anything.

All readers here are monitoring and can chose to point
out when you prefer to be rude to other posters and at the
same time claiming to minding your own business.

If I don't like what someone has said
to me, then he or she is going to hear about it. If you don't like it,
then I suggest that you don't read it.

If you don't want comments then don't post.

Arne

 

[Arne Vajhøj]

And let me tell you something else. I understood exactly what the op was
saying. I brought up objects as a means to control the condition.

I am not sure that it is "better" to understanding the problem and
post a misleading answer than it is to not understand the problem.

And I
also mentioned learning oop(s) in the basic understanding of using objects.
Of course, you had to blow it up out of proportion.

Objecting to rude behavior in newsgroups is not out of proportion.

I have been programming for over 30 yrs professionally. So don't think
in your wildest dreams that I didn't understand what the op was talking
about.

Maybe programming in 29 years and 1 year working on soft skills
would have been better.



Arne

 

[Arne Vajhøj]

I disagree on the force unlocking with WCF if number of connections is
set to 1 and open connection timeout is set to seconds. The WCF service
is only going to allow 1 client and the client is only allowed so many
seconds to have the service complete the task before the connection
closes and another client can be serviced.

That is a timeout solution.

Just like it can be implemented with many other technologies.

I flatout disagree with you. The programmer need not write any code to
set this condition and WCF will handle it. The programmer must have
exception handling on the client side to work with the two exceptions.

That is a solution that require very little writing - not code
just config. Which is good.

But it is not a solution that I would recommend.

In case of a network problem that causes both ends to register
a connection failure then a race condition would happen between
the client that had the lock and a new client getting the lock.

It is extremely unlikely for that to happen with TCP connections.

But basing a solution to a concurrency problem by assuming that
something extremely unlikely will not happen is not good code.

Arne

 

[Arne Vajhøj]

LOL, boy you have some serious issues, you lumatic. You use to be ok
when there was a lot of traffic in this ng. Things kept you occupied.
Now, that the ng has fallen on hard times, all the action is in the MSDN
forums, you have gone completely out of control, sheriff.

I have not read your lip service. You are important to yourself. To me,
you are nothing but someone that apparently has no life, other than
posting endlessly in an abandoned ng, you self-righteous, overbearing,
bored, boring and demented lunatic.

Traffic here seems to be stabilizing, so it is not quite abandoned. Even
you seems to stick around.

And as I believe I have explained before then that type of
name calling in posts stop being impressive around 5th-7th grade.

Arne