algorithmic trading trough chronicle engine

[Vachagan Balayan]

I was checking out the project chronicle-engine and the use case with the algotrading...

And there's something i'm not sure how to do with such architecture. 

As i understand from diagram all the current orderbooks for the markets that the system deals with are stored in a single persisted chronicle-map (and is updated by different process)...

Now suppose an update triggered a calculation of a Strategy.

Strategy runs, it reads the orderbook to see if there are any opportunities, now how do we guarantee that while this strategy reads the orderbook it is not being changed concurrently? (i understand that strategy may run for few microseconds but still its possible to have corrupted state right?)

In my current system I get streams of orderbook events, and i batch them, I apply a batch, run all the bots then repeat forever... (lmax disrupter under the hood)

In this case i can never have state of the orderbook changed while i'm executing a strategy... even if some event happened it wont be applied and i will determine that calculation was outdated later.

I understand this is not really a question about engine but i cant really picture any easy way trough this... Any advise appreciated.

[Peter Lawrey]

You have two approaches.

You either;

- lock the entry, explicitly or implicitly (Chronicle Map support locking of an entry implicitly)

- you have only one thread which accesses the state of an individual entry/actor/order etc.

Either way you can prevent seeing a concurrently updated entry because it is not completely concurrent.

Regards,

   Peter.

--
You received this message because you are subscribed to the Google Groups "Chronicle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-chronicl...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Vachagan Balayan]

Thanks i understand first approach, 

regarding second approach, i actually have single thread reading, but the writer thread is different (different process even),

now say my reader starts to read the orderbook, it reads first 10 orders, at this moment writer updates first 20 orders, my reader keeps reading and gets the updated other 10... wouldn't that be corrupted state as well? I understand that whenever it reads it reads correctly the most up to date state, but the whole orderbook read is a single transaction for the strategy calculation right? I suppose that before reading any next order in the strategy i must check if the entry (the entire orderbook) had any modifications?

[Peter Lawrey]

For this sort of activity, I highly recommend using Queue instead.  This has the advantage of recording (for auditing and replay) all the data including state changes and you can control atomic transactions of any complexity.  Map is really designing as a key-value store where each entry is atomic not multiple entries.

--

[Vachagan Balayan]

Awesome, I was looking into that diagram and thinking maybe i'm totally misunderstanding the design of algotrading app using open hft tools...

Just to make sure i understand the queue approach. 
Each market will have its chronicle queue, 

which has all orders from the moment the collector was running, and the current state of the actual orderbook = all orders till the very last one applied to some orderbook representation that is in memory not persisted anywhere... right?

[Peter Lawrey]

You need one or more queues, which contains message from one or more sources.

Each worker thread reads from the queue(s) and update a local state for any indexed data it needs.  This could be indexes into the queue itself as any message can be replayed.

A given message can consist of a transaction which must be executed in total or not at all.

To work out the state after a restart, you can read from the output queue all the the outcomes which may, or may not have been read downstream.  These are the results you are committed to.  Anything else which was read, but didn't produce a complete message didn't really happen.

--