Yes, locking mechanism is what I am after. But my question what is a "technically correct way" of implementing one.
--- In flexcoders@yahoogroups.com, "Gregory Kelley" <gkel...@...> wrote: > > It is my humble opinion that you would need to initiate some type of > locking mechanism. The process locks until the one process is done. If > you have an application level backend then that could have a lock > variable with a unique ID to the specific process. when it is complete > you push your synchronization and wait for the next request. Another > option might be to package a request as a bundle and submit the package > 1 tme and pull the update to that station. If a process is in process > you don't auto update until that process is complete. When there is no > process in progress then you have it pull on a timer. > > That is if I have read your post correctly. :-) > > Greg > > ________________________________ > > From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On > Behalf Of markgoldin_2000 > Sent: Monday, March 09, 2009 10:12 AM > To: flexcoders@yahoogroups.com > Subject: [flexcoders] Looking for a design pattern > > > > I am working on an application which purpose is to track a task time. > Users are checking in and out of tasks by scanning their badges. > Scanning stations are installed around a shop. Currently I have 5 > stations. I would want to have all these stations showing identical > data. For that I have a mechanism of syncing all stations at the time > when a user scan his ID or enters a task to work on. Another words, any > change on one station is triggering data refresh on all stations. > Everything works fine, but with one problem. In the morning when > scanning is the most extensive, there is a situation when a user scans > his ID and at the same time another user scans on another station. This > collision would change DataGrid's higjlighted record to a record of the > second user and first user would be entering his task into a wrong > record. What would be a design pattern of managing such solution? > Any idea is very welcome. > > Thanks, Mark >