4 ms·

In regards to your comments: 1. relaxed guarantees, "As a consequence the LMAX team puts a lot of attention into ensuring the input events are fully valid befo

by koevet 15y ago

In regards to your comments: 1. relaxed guarantees, "As a consequence the LMAX team puts a lot of attention into ensuring the input events are fully valid before doing any mutation of the in-memory persistent state.". It looks like they deal with inconsistency at the business logic level instead of delegating to the persistence store. Probably, they don't have very complex transactional logic. 2. Smart data structures, here http://disruptor.googlecode.com/files/Disruptor-1.0.pdf http://disruptor.googlecode.com/files/Disruptor-1.0.pdf you have a deeper technical view of the Disruptor and the rationale behind "mechanical sympathy".

jacques_chester 15y ago
> It looks like they deal with inconsistency at the business logic level instead of delegating to the persistence store. Actually it looks the other way around. As I read it, the "Input Disruptor" does the validation. Do the three components all run in the same thread, or are they on different JVMs?
- koevet 15y ago
  The Disruptor components are not part of a single threaded process, as far as I understand "Also these three tasks are relatively independent, all of them need to be done before the Business Logic Processor works on a message, but they can done in any order. So unlike with the Business Logic Processor, where each trade changes the market for subsequent trades, there is a natural fit for concurrency." I think that the Disruptor can run on the save JVM as the business logic, also to avoid remoting-related bottlenecks.
  - _grrr 15y ago
    The hand off between producer and consumer can be configured to be both synchronous (single threaded) as well as asynchronous (one producer thread, many consumers threads).
  - aaronblohowiak 15y ago
    The BLP is single-threaded, and the component that modifies the application's current state. It is my understanding that "Events" in event-sourcing are immutable and that state is just a memoized computation over the total journal of events -- so the layer of atomiticity that is provided is at the event level (as the BLP only processes one event at a time.)
    - jacques_chester 15y ago
      So the system is as "weak as its strongest link". Hmm.

by koevet 15y ago

jacques_chester 15y ago

> It looks like they deal with inconsistency at the business logic level instead of delegating to the persistence store. Actually it looks the other way around. As I read it, the "Input Disruptor" does the validation. Do the three components all run in the same thread, or are they on different JVMs?

koevet 15y ago
The Disruptor components are not part of a single threaded process, as far as I understand "Also these three tasks are relatively independent, all of them need to be done before the Business Logic Processor works on a message, but they can done in any order. So unlike with the Business Logic Processor, where each trade changes the market for subsequent trades, there is a natural fit for concurrency." I think that the Disruptor can run on the save JVM as the business logic, also to avoid remoting-related bottlenecks.
- _grrr 15y ago
  The hand off between producer and consumer can be configured to be both synchronous (single threaded) as well as asynchronous (one producer thread, many consumers threads).
- aaronblohowiak 15y ago
  The BLP is single-threaded, and the component that modifies the application's current state. It is my understanding that "Events" in event-sourcing are immutable and that state is just a memoized computation over the total journal of events -- so the layer of atomiticity that is provided is at the event level (as the BLP only processes one event at a time.)
  - jacques_chester 15y ago
    So the system is as "weak as its strongest link". Hmm.