In which actual situations do you need to do dbSync -> commit upd as opposed to just commit upd? It seems to me the RMDBS equivalent is begin -> commit?
If you do db, put> and commit upd calls so that they happen roughly at the same time you should be as safe as you are when you do a "update table set bla bla where userid = 5" in an RMDBS? Let's take what I actually do at work as an example, pretend that I would like to try to move the whole casino database from MySQL/InnoDB to PL, the main thing then would be the following SQL query for example: "update users set balance = balance + 10 where user_id = 50". There can be 100 such calls per second and upwards 5 of them per second for the same user. Doing a dbSync here doesn't makes sense, there are no relations, just a number that needs increasing or decreasing, updating user 5's balance should not have to wait for an update of 10's balance to finish and so on. It seems to me that this situation is solved in PL by simply doing (commit upd)s without any dbSyncs, if there are several updates coming in at virtually the same time they will still be synced through the commit upds. Also I can NEVER put> the balance but have to use dec> and inc>, just like in the RMDBS scenario, doing a "set balance = 100" somewhere would be suicide, apart from that I should be ok I think? But the most common scenario though would simply be a (commit), ie we don't care who gets there first or not. On Sat, Jan 5, 2013 at 11:44 PM, Alexander Burger <[email protected]>wrote: > On Sat, Jan 05, 2013 at 11:25:30PM +0700, Henrik Sarvell wrote: > > How does the GUI framework work? > > > > What if user A pulls upp object X in an update form and then goes to the > > toilet and in the meantime user B pulls the same object and changes it, > > will user A see any changes when he comes back? > > Yes. Try it ;-) > -- > UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe >
