To be honest, this is old-hat for database programmers, yet it's rarely discussed in Flex/Flash circles and largely ignored in most web discussion. Things tend to move up a notch in complexity once you have to consider multiple users and databases.
Usually I tend to favour optimistic locking schemes on the database since they don't cause problems with interactive users (send me a PM and I'll try and explain it if you aren't already aware). The real issue is that potentially with multiple users (with or without a database) data can be changing data underfoot, so there are a few issues. 1) protecting data from unprotected updates that would lose or corrupt data; 2) keeping the user interface updated with changes made by other users/processes (which means merging the new data with what's already presented to the user) Using flags in a database to indicate what's going on in the user interface is to be avoided. The particular danger with flag setting in a database to indicate what's happening in the user interface is that there will be cases where the user interface will not complete it's work leaving the database with flags set indicating some operation is happening when it isn't. This could be a long discussion.. I was hoping for a few war stories or snappy techniques. Paul ----- Original Message ----- From: "jbeck_sound" <[EMAIL PROTECTED]> To: <flexcoders@yahoogroups.com> Sent: Thursday, September 14, 2006 4:32 PM Subject: [flexcoders] Re: Data synchronisation tip and tricks? > Very good topic! I'm working on a RIA using Flex that deals with a > similar situation for an online ticketing system. Imagine two or more > folks selecting the same seat and wanting to purchase a ticket for it. > Essentially this is collision bound, unless it is being handled carefully. > > I see two solutions: > > a) Use Flex Data Services and it's real-time features of updating > clients with the latest status on a specific room (in your scenario). > This will not completely eliminate the possibility that both customers > want to book the room at the exact same time. However, it will cut it > down quite significantly. Of course, there is some additional stuff > going on that we would have to take into consideration. > > b) Use flags in the database records for each room as to its > availability and return a response to a customer when the booking is > committed. If someone else has beat them to it, then an error would be > returned, eventually halting the rest of the transaction based on the > fact that the room now is no longer available. > > This is a very birds-eye view of what would need to happen, at least > in my mind. There may be other approaches and solutions to this > problem and I would be interested to hear them! > > Jurgen > > --- In flexcoders@yahoogroups.com, "Paul Andrews" <[EMAIL PROTECTED]> wrote: > > > > Most of the traffic conversation here seems to revolve around > applications > > that are essentially read-only or are behaving as though they are single > > user. > > > > Any tips and tricks to be found regarding the synchronisation of > data in a > > multi-user application involving a database. > > > > For example (since hotel booking is a prominent example in the RIA > world), > > lets suppose I have two customers (Customer A and Cust B) trying to > book the > > same hotel room on the same day. Both see it as free in the RIA, Cust A > > books it and now the other must know about it too, so effectively then > > that's a straight refresh of Cust B display and the aborting of the > booking > > in progress. > > > > Lets suppose my application allows Cust B to mark several days of room > > bookings and (s)he has to hit 'book now' to commit to the booking. While > > this is going on 'Cust A' has booked one of those days, so now I > must merge > > the updated database with the on-screen representation, so it's no > longer a > > straight replacement of the application display from the database, we're > > having to merge. > > > > Perhaps I'd best not even mention database locking and handling that > in a > > RIA. > > > > Get the idea? I appreciate this isn't entirely Flex specific. > > > > If there are tips and tricks/best practices in this area with regard to > > Flex, I'd like to know about them before I re-invent the wheel! > > > > Paul > > > > > > > > -- > Flexcoders Mailing List > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com > Yahoo! Groups Links > > > > > > > > > > > -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
