[MUD-Dev] C&C and Event Rescheduling

[Jon A. Lambert]

> From: clawrenc at cup.hp.com
> Subject: [MUD-Dev]  C&C and Event Rescheduling
> 
> In <33CFCE6E.41C67EA6 at iname.com>, on 07/18/97 
>    at 01:22 PM, Shawn Halpenny <malachai at iname.com> said:
> 
> >Yep, a slight change is necessary.  Now (and again, roughly): 
> >1.  A client C requests object O from the database. 
> >2.  Add C to list of clients using O. 
> >3.  Return OC (a client-only copy of O) to C. 
> >4.  A client D (which may or may not be the same as C, but is on the
> >    using-list for O) returns OC'. 
> >5.  If O has not changed since D's request for it (a different client
> >    may have committed changes to O while D was processing), OC' is
> >    atomically committed to the database, replacing O.  D is removed 
> >    from O's using-list.
> >6.  If O has changed since D's request for it, OC' is discarded and D
> >    receives notification that OC' couldn't commit.
> >7.  Clients in the using-list for O are asynchronously notified that
> >    O has changed. 
> 
> Given that this basic pattern extend to all the objects which comprise
> a given event or transaction, this is identical in principle to my
> model.
>

This might be accomplished by separating methods into event methods 
and regular methods.  A regular method is never called by the event 
manager since it isn't a logical transaction, while an event method 
forms an application consistent transaction.  Upon termination of an 
event method an implicit commit is done.  This should allow nested 
transactions as a side effect of nested event method calls as long 
as commits are delayed to the callers termination.
 
>   There is reason behind all this madness:  It reduces the number of
> data copies needed for transactions.  By using this sort of layered
> scheme I manage to delay making a copy of the object until I
> absolutely need one (ie someone has attempted to modify the object). 

On further thought, the amount of object copies doesn't bother me
to much as a performance issue.  Many well-optimized locking DBs do 
this as a matter of integrity.  The wasted time and possible race
conditions in event rescheduling vs. wasted time waiting on "a lock" 
and possible deadlocks do bother me.  I can't really make an informed 
guess as to which is better.  Some heavy duty profiling is probably
in order.   

> 
>   Re: #5.  How do you determine that the object has changed during the
> execution of the event?  I do this by always keeping an original copy
> of the object to compare to the copy current in the DB and then do a
> bit-wise comparison of the two objects.  The original copy is the
> second copy made above for a modification.
> 
>   Aside: I'm actually getting *slightly* neater than this as the
> current plan encludes only making a copy of the object
> attribute/member which is changed, and then only comparing that at
> C&C.

The burdens of attribute detection are difficult.  How does
one detect the difference between:

ObjectA method ()
{
   x = ObjectB.attrX;      // a direct reference
   y = ObjectB.GetattrY(); // an indirect reference through accessor
                           // perhaps a derived attribute?  
}


Another possibility is for the DB manager to push the requesting
events unique handle onto an interested parties list along with a 
CRC.  Upon an attempt to commit, you compare the stored event handle's 
CRC to real objects CRC.  Problem: How reliable is CRC-32/64?  
Worst case: the 1 in 32 billion(?) burp causes an invalid pointer 
reference followed by a big thump.  On reboot and reload of DB 
the invalid object reference is ideally gracefully groked.  
Another issue:  A performance judgment on CRC calculation vs. 2nd object 
copy with memory/bitwise comparison.


> 
> Concern:
> 
>   An event generated IO.  How do you handle when it reschedules? 
> Think about things like SAY, TELL, LOOK, etc for example cases.
> 

You also mention somewhere below about how some objects undergoing
a state change will propagate/generate events (likely asynchronously).
I see these objects being very similar and/or handy with IO.
Maybe it's possible for either the DB manager or the VM to post
the object state change events to the event scheduler after the 
point of a successful transaction commit.
This might require another special method/object language construct.  
It would handle indirect state changes as long as the room container
is the primary propagator.  And yes, even a temporary "neighborhood"
object could be born from the commit and die at the end of it's
state change method *boggle*
A global CHAT object could then spawn gobs of events during its
cycle through the world.  

> Okay, 50 players in a room all moving west is unlikely.  How about 50
> players in or near a room, some moving out the various doors, some
> coming back into the room having left, others picking up or dropping
> various objects (changes to the contents lists), Every single event is
> now compeating for the chance to get a single unmodified copy of that
> room when it C&C's.  
> 
> Now that I've cast doom and gloom.  This need not be a huge problem. 
> The fix is to change the manner in which you write
> events/transactions.  The requirement is to split events into the
> smallest, fastest executing,  logically consistant units you can.  The
> idea is that by making the runtime of an individual event as short oas
> possible the chance of collision by other events is minimised. 
> Further, by making the runtime short, the probability is that what a
> given event sequence contends with on its first step will not be
> contended for on its next step.  eg:
>

You could go to a pure event model, where ALL method references are
considered object messages which are dispatched as events.  I have
doubts whether any sort of application transactional integrity
could be easily achieved with this approach, unless there is a strong
in language mechanism in place.   ala StartTransaction-EndTransaction.
This takes the implicit nature of persistence out of the language.
Blech...IMO implicity==simplicity for the potential mudlib coder.

[execution priority and starvation trimmed]

I need to look at this closer. 
I agree with most of this conceptually. =)



JL