[sldev] How Asset server handles saving of scripts
Kelly Linden
kelly at lindenlab.com
Wed Dec 19 17:46:22 PST 2007
Erik Anderson wrote:
> You sure about this? I always thought this was a caching issue, so a
> sim can say "the UUID is one that I already have, and assets cannot be
> modified, so no reason to ask for fresh content from the asset
> server". The thing is, prims aren't affected by this "dirty write"
> system, why just notecards and scripts?
>
> On Dec 19, 2007 3:26 PM, Hamncheese <me at hamncheeseomlet.com
> <mailto:me at hamncheeseomlet.com>> wrote:
>
> This is done probably for performance reasons. It is more
> performant to
> insert a new row in a table than to locate, lock, and then update,
> release
> lock.
>
>
>
An asset system vs inventory vs simulator run down might be useful here.
The asset system is a giant ass web server cluster that implements the
fairly standard WebDAV interface. It is fancy only in its design for
redundancy and handling large amounts of requests. I am not going to
comment on today's issues any more than to say some things don't always
work the way they should. :(
"Assets" are stored static datasets that are always written just once.
All textures, notecards and scripts fall in this category, as well as
landmarks and clothing items etc. These are items that don't get
simulated, as well as objects (which do get simulated) that are not
currently being simulated. These are essentially files on the giant ass
web server cluster, they aren't being actively simulated and they don't
exist in a DB. So when you take an object into inventory the dataset
that describes the object is saved to the asset system, and a row is
updated in the DB for the inventory item (see below). Yes the write
once helps tremendously with caching, you know if you have that specific
version of an asset by the ID alone.
Inventory on the other hand is stored in a Database and is essentially a
set of links to assets plus some meta data (mostly relating to
permissions). When you rez an inventory item what really happens is the
simulator looks up the asset ID for the specific inventory item and
pulls the data from the asset system to create a copy to actively
simulate. It also applies any meta data changes made to the inventory
item to the newly rezed object.
Objects that are in the simulator are actively being simulated. Their
state may differ significantly from the asset that was originally rezed,
and no new version is saved to the asset server until it is taken into
inventory. Simulators themselves create assets known as Simstates on a
regular basis that are a serialized version of the state of the entire
region being simulated including the data that would be an object's
asset. These simstates are created on a regular basis and stored either
on a local simulator host or (usually) on the asset server.
When you save a script new assets are created and uploaded through the
simulator (or caps server) to the asset cluster. If modifying a script
in your inventory the inventory DB must be updated to reflect that it
points to the new asset. If it is a script in an object the simulator
can update the asset id that object-inventory item points to purely in
memory.
Maybe that will cause more clarity than confusion .... but maybe not. :D
- Kelly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071219/ae423e1b/attachment.htm
More information about the SLDev
mailing list