Notifying other running instances of my app of changes to list contents.

  • Thread starter Thread starter idletask
  • Start date Start date
I

idletask

I have an application that has many windows. One window is used for
order processing. I would like this window to display the other users
who are also performing order processing (the idea is to prevent a user
from opening an order that is being worked on by another user.

I have considered using the database:

* my query can return a user id or other identifier along with the
order record so that when I populate my list view control, I can
display the user who is working on that record.

* if the user trys to open one of these records I can tell them
'someone else has this right now'.

* I want to avoid hitting the database to update this list using a
timer control and multithreading (the reason I would do that is to
periodically update each users list view with the most current users
using whatever order).

the bad part of this idea is that when the window initially loads and
populates the list, it only knows about the other users at that time.
the user would click on something that looks 'open' to them only to
find out it's not really open to them.

I'm looking for a way to make my order list more dynamic- meaning, if
user A has the order list widow open, and so does user B, I want the
window user B is using to be aware of user A's change (open a new order
for processing).

Am I on the right track? Is the list view not the right component? I
know gridview and datagrid can be sensitive to database changes, but I
cannot see how I can avoid the use of a timer in any of the above (or
will the grid component's automatically sense changes to the database
outside of themselves?).

I'm considering using some type of network communication to get these
messages across. Is this a good idea, or bad?

thanks for any thoughts- I am really stuck here. I'm concered that I
am missing something easy and obvious...
 
IdleTask,

What you're asking is the difference between pessimistic and optimistic
concurrency.
A not so simple problem to answer in a newsgroup.

Pessimistic concurrency is based on the fact that in a database two users
can update often the same data at the same time.

Optimistic concurrency is based on the fact that time has learned that the
first situation occurs in most standard situations seldom, however that
errors because of that has to be prevented, so there is a checking
afterwards if something has been changed in the meantime.

Pessimistic concurrency is very difficult to do without getting the change
on deadlocks. It has as well a very hug impact on the performance of a
database (the reason that is not anymore in AdoNet while it was in Ado).

Therefore it is in my idea better to over think your plans again.

http://msdn.microsoft.com/library/d...s/cpguide/html/cpconOptimisticConcurrency.asp

I hope this gives some ideas

Cor
 
Hi

Another possible alternative for you is, instead of listing all orders
to be processed along with the name of the user currently dealing with
it (if there is one) is to have a button on your form (called something
like "Get order to process") which will pull one order out at a time
and when an order is pulled out by a user to work on you can mark this
order as 'checked out' or whatever. This way you can ensure that only
one person is working on an order at any given time and you'll only be
hitting the DB when they're ready to process an order, and they'll only
see orders that are not being worked on (plus you'll only be retrieving
one order at a time from the DB so the performance shouldn't take a
nosedive).

Alternatively you could code a queue of available orders, once a user
has 'checked out' an order to process, it gets removed from the queue
(although with this option you'll obviously have to continually poll
the DB to refresh the queue).

I suppose it really depends on what you want to achieve.

If you want all the users to be able to see all the orders, along with
details of who's working on them, you've really got no alternative than
to poll the DB frequently to ensure the view they have is up to date,
(either that or have something like the following implemented so you
only poll the DB when you know there's been a change:
http://www.codeproject.com/cs/database/DatabaseEventsArticle.asp).

If you just want to stop people working on an order that's already
being processed, then don't give them the option - i.e. pull
one/five/however many orders you think they can process and flag these
as checked out so other users can't get at them.

Hope that helps
Martin
 
Hey there-

Thanks for your reply. I agree w/ you and the other person's
suggestion that I rethink. Sometimes you get busy and caught up in the
problem and you can over think it :)

Pulling one order at a time is good suggestion and will work for my
needs.

Thanks again (to you and the other person as well).
 
Back
Top