On 2009-07-09, at 04:23, Dale Mahalko wrote: > On Wed, Jul 8, 2009 at 8:37 PM, Argent > Stonecutter<[email protected]> wrote: >> The correct solution (don't rez the object, leave it >> in inventory) seems too obvious.
> This sounds like a potential race condition, since rez requests are > not instant and load-in takes time. Assume two people want to rez > objects on a parcel with limited space. Both attempt to rez a high > prim object from inventory at the same time (or within milliseconds). This is a problem that is covered in freshman CS, in the first database course you take. > 1. The sim does a precheck for space availability for #1, finds enough > room, starts the load-in > 2. Asset system is being slow again > 3. The sim does a precheck for space availability for #2, finds that > another load-in is pending and not completed yet, and so aborts the > rez attempt. > 4. Object #`1 rezzes That's it, the TRANSACTION-COMMIT operation every DBA is intimately familiar with. With a transactionalized system, you can even allow overcommit, and abort (return) pending transactions when one completes. A sim in SL can handle up to 20,000 prims, because there ARE 20,000 prim sims in SL, so allowing up to 5000 prims of overcommit is acceptable. So A says "I need 1000 prims" and it says "OK" and B says "I need 1000 prims" and it says "OK, with 300 prims of overcommit". If be rezzes first, A gets returned. If you try to rez more than the buffer, then you get deferred. If you continue to do so, you get throttled. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
