I used Observer design pattern and Adaptor design pattern to deal with asynchronous problem. It works for me. Maybe you can try it out. home4trade.com has some infomation that I posted.
What are the advantages of using a document oriented database for positions and order? I can think of other use cases for document oriented databases but positions and orders seem well suited to the relational model.
I currently tag all my orders with a reason for entry/exit. Soon, I will programming event based systems, and instead of a small "tag" the cause could be a long article or news story. I would like to store that along with the order for later analysis.
The current one is Hybrid, but all entries and exits are 100% quantifiable. The only thing that is discretionary is the hedging part, and the size to do. The event based system is likely 100% automated.
then why would you need to tag all orders with a reason for entry/exit? isnt it easier to just say that this order is from this strategy.
Because the strategy can generate different order types. This is an option system where there could be several spreads, etc, that defines an "trade", which can be comprised of multiple orders. Also, some contracts get rolled, and they are part of the same trade, just different strikes. Options complicate things considerably over equities. For example, say I am trading a straddle. That is two orders if you enter both legs as separate orders, but as far as the strategy is concerned it is part of one strategy. Or what about a calendar, or things that have 8 legs, or .... Also, as the system evolves, or I have systems that take trades on news stories for example, if I do things right from the beginning, I won't have to change a thing.
OK. I think I (and possibly some others such as propseeker) misunderstood your earlier comments. I interpreted your previous posts as implying that you do not store order state locally at all and instead rely on making frequent data replay calls to the broker's API to request order state information from their servers whenever you needed it. What you are saying here is that you are maintaining local state (or rather the broker's API software is doing it for you). If that's the case then we can put the previous state persistance conversation to bed because we actually all agree that you have to keep state locally (whether it is done by the broker's software or your own is pretty much irrelevant) if you want to avoid making callback requests to the broker's servers every time you need order state information. Let's draw a line under that debate. OK. As I said above. I think I and a few others interpreted your previous posts differently. In the event of a restart following a crash I don't think there's any question that a strategy's state should be rebuilt from scratch using the position/order data persisted by the broker if possible. In fact, if the application misbehaves in any way I think the only safe approach is to consider everything held in memory as potentially tainted and therefore initiate a full restart and recovery. What propseeker was saying earlier though is that if this data can't be obtained quickly and easily (i.e. through the broker's API) then no sane person is going to wait on the phone for it to be read back to them. They are going to use the locally stored state to make best efforts to put on any appropriate hedges. Far better to have hedges in place that reflect that last known state than be sat on the phone trying to get through to some broker who (at best) is going to be stressed and likely to make mistakes in reading data to you or (at worst) completely unobtainable because 100 other people are trying to do the same thing.
I like that. Do the same here, hopefully going live in a week or two. The problem I ahve with most frameworks is that they have no idea what a (logical) trade is (taht may be composed of different legs). The result is that stuff like Ninja.... has totally fucked up statistics for complex scenarios. Look at a spread. Large chance ONE of the sides will be a loss. Depending on how you enter - chance is nearly 100% one side will be at a loss. So, if you loko at each individual item, you geta 50% profit rate. Yeah. Right. This is if you ahve a 100% profitable strategy - still 50% of the positions close out with a loss. Why? No logical trade concept