Re: [flexcoders] Data synchronisation tip and tricks?
- Original Message - From: Tom Chiverton [EMAIL PROTECTED] To: flexcoders@yahoogroups.com Sent: Friday, September 15, 2006 3:36 PM Subject: Re: [flexcoders] Data synchronisation tip and tricks? On Thursday 14 September 2006 16:12, Jurgen Beck wrote: I see two solutions: I have actually seen the 2nd in use on (I think) ticketmaster - during check out it told me the seats were reserved for 20 minutes, and if I hadn't payed by then I'd lose them and they'd go back in the pool. You could probably calculate the chance of a collitsion based on the length of time it takes to do a booking, how many customers there are (at once) and how many seats there are. If the chance in low, and fairly simple 'soft reserve' like the above or you option 2 is going to be best, I feel. OTOH, if collisions are going to be frequent, you want to be more proactive to help the users out - but at the end of the day, two people might just press 'submit' at the same time, and one of them is going to get a rolled back transaction and 'please choose another seat'. The other party may back out later, but there isn't much I think you can do about that. Depending on the checkout process you can prevent the rollback altogether. This all depends on how the checkout process black box works. If the checkout process is a black box that can communicate back with the ticketing system for confirmation that the product is still available: Ticketing system marks seats as 'pending booking' and sets a timeout on this status to protext the seats from booking. Ticketing system passes request to the checkout process to get the money from the user. Checkout process processes everything, apart from requesting money from the bank. User presses 'submit' to confirm transaction and payment details. Checkout process asks ticketing system to confirm transaction can proceed and tells ticketing system how long it will need (max) to complete the checkout process upon confirmation by the ticketing system. Ticketing system checks that seats are still available and that timeout has not elapsed. If the timeout left on the seats is less than the time required to complete the checkout (no more human involvement is now required) the timeout is extended. If the timeout has expired, the ticketing system will check that the seats are still available to the requesting customer and will re-reserve the seats, pending booking with enough of a timeout for the checkout process to complete. If the timeout has expired and the seats are no longer available the ticketing system informs checkout to abort and not to take the customers money, otherwise the ticketing system tells the checkout process to complete the transaction. The checkout process informs ticketing system of the result and the ticketing system will update the seat status and interact with the customer accordingly. Paul -- Tom Chiverton Helping to confidentially create open-source bandwidth This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. -- 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/
[flexcoders] Data synchronisation tip and tricks?
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 * 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/
RE: [flexcoders] Data synchronisation tip and tricks?
Hello Paul - This is an *excellent* topic to discuss, and I am glad you brought it up. I too will face the same issues shortly - except mine revolve more around inventory control - but still, the same problems apply (me selling a product to a customer, when quite literally during the same phone conversation, the product could be sold from right under my feet, due to another sales person making a sale of the same product). Lets hope this thread receives a lot of input, as it will help a LOT of database developers who are writing RIA's - Mike -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Paul Andrews Sent: Thursday, September 14, 2006 9:11 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Data synchronisation tip and tricks? 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/
RE: [flexcoders] 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
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Paul
AndrewsSent: Thursday, September 14, 2006 9:11 AMTo:
flexcoders@yahoogroups.comSubject: {Disarmed} [flexcoders] Data
synchronisation tip and tricks?
Most of the traffic conversation here seems to revolve around
applicationsthat are essentially read-only or are behaving as though they
are singleuser.Any tips and tricks to be found regarding the
synchronisation of data in amulti-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 thesame hotel room on the same day. Both see it as free in the RIA,
Cust Abooks it and now the other must know about it too, so effectively
thenthat's a straight refresh of Cust B display and the aborting of the
bookingin progress.Lets suppose my application allows Cust B to mark
several days of roombookings and (s)he has to hit 'book now' to commit to
the booking. Whilethis is going on 'Cust A' has booked one of those days, so
now I must mergethe updated database with the on-screen representation, so
it's no longer astraight replacement of the application display from the
database, we'rehaving to merge.Perhaps I'd best not even mention
database locking and handling that in aRIA.Get the idea? I
appreciate this isn't entirely Flex specific.If there are tips and
tricks/best practices in this area with regard toFlex, 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
SPONSORED LINKS
Software development tool
Software development
Software development services
Home design software
Software development company
Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group
|
Yahoo! Groups Terms of Use
|
Unsubscribe
__,_._,___
