This project is read-only.

Buffered Implementation

May 26, 2011 at 12:25 AM

Looking at the generated code and have a question..

     /// <summary>
            /// Write any data changes to the BAM activity. This must be called after any property changes.
            /// </summary>
            public virtual void CommitActivityTrackingActivity()
                // We need to provide the key/value pairs to the BAM API
                List<object> al = new List<object>();
                foreach (KeyValuePair<string,object> kvp in _activityItems)
                // Update the BAM Activity with all of the data
                EventStream es = _eventStream;
                es.UpdateActivity(ActivityName, _activityId, al.ToArray());
The use of Flush() in this scenario seems like it should be in the end activity?  In the case above flush is running with every UpdateActivity call.  This seems to defeat the purpose of the BufferedEventStream.  
So you see any downside to moving that flush command to the method below?:
            /// <summary>
            /// End the BAM activity. No more changes will be permitted to this activity except by continuation.
            /// </summary>
            public virtual void EndActivityTrackingActivity()
                // End this activity, no more data can be added.
                EventStream es = _eventStream;
                es.EndActivity(ActivityName, _activityId);
If I am missing something obvious I apologize. I am used to dealing with just the out of the box API. Generally I run flush on a case by case basis, sometimes even setting it to the number of events
I expect to take place in the initialization.  


May 26, 2011 at 5:46 AM

Hi Nathan,

I think it just depends on how you look at the possible usage patterns.  The properties on an instance of this class may be set as many times as you wish without committing anything to the event stream.  If I have an orchestration variable holding an instance of the generated BAM activity class, I'll set the properties throughout the orchestration and (generally) call Commit/End as a pair of calls together in sequence at any orchestration termination points.  It's up to you when you want to call Commit, as long as you do it once before calling End.

Also, the generated class is partial and the methods virtual, so if you want to modify the behavior you can just create a partial class file and override the methods above.

Does that help or make sense?


May 26, 2011 at 7:43 PM



You are absolutely correct, I just wanted to make sure I was not missing something.  I appreciate your work!