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
>


Reply via email to