On Mon, 26 Aug 1996 10:11:57 -0700, JCL wrote:
} On Aug 25, 9:20am, Alex Oren wrote:
}
} > So, the stuff that has to be buffered until the successful C&C is:
} > - I/O (outbound)
} > - Starting of new events
}
} Anything done to an object (create, change, destroy)
} Any IO (I send IO as seperate events chained off E_SUCCESS as above)
} Dependant events (ie the at_exit stuff above)
}
} > Did I miss any?
}
} That seems pretty compleat.
}
} > (I think that no special treatment is needed for creating/destroying objects,
} > since they may be created in the cache and written tto tthe DB along with the
} > other C&C changes).
}
} That is my assumption, tho the DB needs to be explicitly tailored to handle
} this, and to temporarily assign and reserve valid ObjectIDs.
Good point.
} Object creates
} and destroys are really of a different class of DB-level events than object
} content changes.
Which brings me to a discussion we were having on a different thread: having
properties as parts of the object or as standalone objects.
Consider:
Assume three properties on the PLAYER object: Inventory, Gold and Hits.
[Bubba, Bozo and Googoo are in a room]
Googoo> drop sword
Bubba> give 20 coins to Googoo
Bozo> kill Googoo
All three commands invoke events that change the state of the Googoo object,
possibly failing and re-executing due to C&C contention. The events will have to
be executed serially.
Now, if we change the model so that each property becomes a DB object in it's
own right (I believe that is what ChrisG uses) there is no contention and fully
concurrent execution is possible.
OTOH, one may argue that most of the contention will be for containment
properties anyway (inventories, rooms, etc.) so we will not gain much.
Comments?
Have fun,
Alex.