OnBarUpdate vs. OnOrderUpdate Threading?

[BigWaveDave]

Hi:

I've got an advanced strategy in the works that uses Unmanaged order processing.

The scenario that I'm seeing occurs when I call ChangeOrder from within OnBarUpdate().

What I'm seeing is that sometimes before the Change order request completes transitioning through all of the order states back to OrderState.Working, another OnBarUpdate is coming through which is causing me some issues...

So, first, can someone confirm that OnBarUpdate and OnOrderUpdate are each executing in separate threads? Assuming that the answer is yes, are there any built in synchronization objects that exist to help coordinate execution between the two threads?

If not, does anybody have any recommendations on the ideal way to deal with this in Ninja? I can create my own mutex or critcal section if necessary, just wondering if there's a prescribed way that Ninja suggests handling this issue...

Thanks,
Dave

[NinjaTrader_PatrickH]

Hello Dave,

Thank you for your post.

You are correct, OnBarUpdate() can be called before the orders is returned as working, as a tick can come in at any time.

There is nothing built in to make the OnBarUpdate() method call queued until the order returns as working. However, what are you experiencing that you wish to avoid?

I look forward to your response.

[BigWaveDave]

Thanks for the quick reply...

I'm modifying some values in OnBarUpdate() that are impacting the way my handler in OnOrderUpdate() for the 'Working' state operates.

Specifcally, I'm calculating a new EntryOrder price storing it off in a variable and calling ChangeOrder from OnBarUpdate(). If this occurs a second time before the previous ChangeOrder call transitions my order into 'Working', my stored EntryPrice is no longer in sync. with the price contained in the IOrder object. I have code in OnOrderUpdate that does stuff when the IOrder Price doesn't match my separately maintained price. So essentially the two are getting out of sync.

Why do I store the entry price separately from the IOrder object? Well, because my strategy needs to know what the entry price is even there is no IOrder object for the entry yet. Additionally, I'm using the 'working' state in OnOrderUpdate to try to detect if the user has moved an order in the DOM so that I can sync. my internally stored entryprice with the new 'externally' modified price.

I have stuff I only want to execute inside of OnOrderUpdate 'working' if my internal price is out of sync. with the IOrder price.

I don't really wanna synch. the two threads... that seems unnecessary. Unless you can tell me another way to detect if the user moved an order in the DOM from within my Strategy, I guess I'll have to just rework my implementation a bit.

Thanks,

[BigWaveDave]

To simplify. I want to set a flag when the user moves an order in the DOM. I need to distinguish somehow between an internally adjusted price (through ChangeOrder for example) and one that is changed externally of my Strategy.

[NinjaTrader_PatrickH]

Hello Dave,

Thank you for your response.

I am not familiar with a method to detect a user moving the order price in the strategy, I am not even familiar with methods to pull information from the SuperDOM. These would be unsupported if available, it is possible one of our support forum users is familiar with this though.

[BigWaveDave]

Thanks Patrick.

Ok, for those who may be interested (which is probably nobody)... I have decided that I'm going to maintain a FIFO queue of price + order objects, inserting one at the head for each ChangeOrder request that I invoke from within OnBarUpdate(). (maybe I can get away with just a queue of order objects).

When the OnOrderUpdate() 'Working' state eventually comes thru, I will compare the IOrder Price against the tail of the queue instead of my internally maintained single variable. There should be a sequential match for every OnOrderUpdate() coming thru that was initiated by an actual ChangeOrder call. If the Order price does not match the tail of the queue (or, of course, if the queue is empty) this will indicate that the price change occurred externally (i.e. from the DOM or control center). This will only work if order state transitions come through synchronized with the ChangeOrder requests... In other words, the first 'working' state event matches the first ChangeOrder request, etc. I'm assuming that will be the case.

It's a pain, but I can't think of any other clean way.

Thanks anyway.