OK so how would you deal with a situation where you have the need to quickly increment people's balances like I mentioned previously but at the same time you have another process that has to update a lot of objects by fetching information from many others?
This second process will take roughly one minute to complete from start to finish and will not update +User in any way. If I have understood things correctly simply doing dbSync -> work -> commit in the second process won't work here because it will block the balance updates. Another option would be to do it in a loop and use put!> which will only initiate the sync at the time of each update which should not block the balance updates for too long. The question then is how much overhead does this cause when it comes to the balance updates in your experience? If significant is it possible to somehow solve the issue of these two processes creating collateral damage to each other so to speak? On Sun, Jan 6, 2013 at 7:19 PM, Alexander Burger <a...@software-lab.de>wrote: > On Sun, Jan 06, 2013 at 05:43:06PM +0700, Henrik Sarvell wrote: > > > Yes, but the caching issue is not resolved. If two processes increment > > ... > > I'm not sure I follow you with that, when I do my testing with the > > following code: > > ... > > (do 10 > > (inc> U 'balance 10) > > (commit 'upd) > > (link (; U balance)) > > (wait 2000) ) ) ) ) ) > > ... > > I get (110 120 120 130 140 150 160 170 180 190) as the result of > > ... > > Seems to me that incRepeat gets the decrease alright? > > This works because 'wait' is an idle loop, which also synchronizes in > the background. > > Try a busy loop like (do 10000000) instead. Then the above code will > happily increment the local balance, no matter how much other processes > decrement the value in the meantime. > > > 'sync' uses the internal mechanisms of 'wait', but in addition to that > also addresses the issue of race conditions, which are difficult to > reproduce with your setup. 'sync' guarantees that notifications about > changes done by one process are sent _atomically_ to all other > processes. > > ♪♫ Alex > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
