On 14/07/11 13:40, David Wolverton wrote: > Perhaps a more interesting example might be -- what if your business model > would make it more efficient to move one of the files 'off world' to a SQL > store on another machine?? If you 'called' a subroutine to do your reads > and writes, those could actually handle that 'File A is now an SQL file > while File B is still UniData' and handle that 'migration issue' with no > changes to any business logic. When your program made a 'call' to read Key > XYZ from File A, at one time it was a 'direct read' while now it's SQL query > for that data to another machine -- the only program that changes is your > 'READ' and 'WRITE' program being able to intercept and mangle the data such > that the 'business logic' program just gets the MV record structure it was > asking to retrieve. > Going back donkeys years ... when I first started programming I wrote an accounts app. As far as the user was concerned the update appeared on the screen just fine - I used whatever data happened to be current. HOWEVER.
Only when the user said "transaction complete" did I rerun the transaction, with locks (actually, files open read-write rather than just read), and commit the transaction. I know that doesn't always work well, especially if you want to reserve stock and stuff - the user won't want to order goods only to find that stocks have disappeared between creating the order and committing it. But there's an easy way round that - just have a "stuff currently being ordered" file - when accepting the order create a record for the user in this file, then check to see that there's stock for all orders currently being processed. Have some mechanism for cleaning out stale entries so crashed sessions don't hog all the stock. Just think outside the box, try and store the transaction in the web session, and only commit it once the user has said "yes go ahead". If the session visible to the user shows data that's a couple minutes out of date, does that really matter? I know the answer could be yes, but usually it's "no not at all". Cheers, Wol _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
