[sldev] "Prim Journal" size (was: Unexpected objects return in group land)

[Boroondas Gupte]

Dale Mahalko schrieb:
> Perhaps what is really needed is the capacity for a load-in of prims
> to be backed-out via a form of disk-partition journaling /
> transaction-tracking. If the parcel is found to be full when the
> load-in is asynchronously completed by the asset system, it can be
> safely backed out from the journal data.
>   
Sounds good. I think this should be the way to go if Tirgo's suggestion
of counting the object's prims before the actual rezzing isn't possible
(e.g., because that would require some recursive asset server queries
with unknown reaction time).
> But next you run into problems of deciding how big this journal should
> be, since it adds more processing burden to the sim, to track the
> rezzing of everything in the sim in order to permit rez back-out.
>
> If a sim allows 15,000 objects then the journal should probably be a
> few multiples as large, since it is apparently theoretically possible
> to attempt to rez a 15,000 prim coalesced object in an empty sim. If
> two people try this at the same time the journal would need room to
> buffer the insane amount of rez overflow, and not wreck the rest of
> the existing sim.. so a 45,000 prim journal should be unreasonably
> large enough. :-)
>   
Is this size really necessary? I'd assume a coalesced object is
represented on the asset server as a list of references to the contained
objects + their relative position/orientation. The inventory itself has
a reference to that list. So, when a (no-copy) rez is requested,

    * remove the reference to the list (i.e. the coalesced object) from
      the inventory, but keep a copy of that reference in the journal
          o also, don't delete the list from the asset server, yet
    * try the actual rez
    * if the rez fails (for whatever reason)
          o roll back the emergence inworld of the already rezzed parts,
            e.g. in the same way as that's already done today
          o roll back the removal of the coalesced object from the
            inventory by re-inserting the reference saved in the journal
    * if the rez succeeds
          o tell the asset server to abandon the coalesced object
          o clean up the journal by removing the save reference

So, if my assumptions are correct, the journal would only need to be
able to hold as many references as there would be concurrent rez request
being worked on. All the rest of the data would already be on the asset
server and we would just have to keep it there for some short time longer.

cheers
Boroondas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090709/fd5b8fd4/attachment.htm