PHP Event Sourcing Projections
Ecotoneruns the projections synchronously with your aggregate changes. This kind of running configuration can be used to avoid eventual consistency problems or for testing purposes. However when you expect multiple accesses to your Aggregates at the same time, you may consider asynchronous projection to protect yourself from concurrency problems.
You may run your projection in the background. It will query the database within constant time intervals, to look if new events have been registered. Each projection is running as separate process. To register Polling Projection make use of ServiceContext.
public function basketList()
Then we can run:
bin/console ecotone:run basket_list -vvv
artisan ecotone:run basket_list -vvv
The difference between
Event Drivenprojection is the way they are triggered. The
Event Drivenis only triggered when new event comes to the system. This avoid the pitfall of continues database access while using
Polling Projection. The second strength of Asynchronously Event Driven Projection is possibility of registering multiple projections under same channel (which is same consumer).
You may customize your Event Sourcing configuration with following configuration:
public function configureEventSourcing()
->withEventStreamTableName('event_stream') // name of event stream table
->withProjectionsTableName('projections') // name of projection table
->withInitializeEventStoreOnStart(false) // will check and create above tables if needed
->withLoadBatchSize(1) // amount of events loaded on each projection run,
public function projectionConfiguration()
load_count //Default: null
Change load batch size in each run for single projection.
cache_size //Default: 1000
The cache size is how many stream names are cached in memory, the higher the number the less queries are executed and therefore the projection runs faster, but it consumes more memory.
sleep //Default: 100000
The sleep options tells the projection to sleep that many microseconds before querying the event store again when no events were found in the last trip. This reduces the number of cpu cycles without the projection doing any real work.
persist_block_size //Default: 1000
The persist block size tells the projector to persist its changes after a given number of operations. This increases the speed of the projection a lot. When you only persist every 1000 events compared to persist on every event, then 999 write operations are saved. The higher the number, the fewer write operations are made to your system, making the projections run faster. On the other side, in case of an error, you need to redo the last operations again. If you are publishing events to the outside world within a projection, you may think of a persist block size of 1 only.
lock_timeout_ms //Default: 1000
Indicates the time (in milliseconds) the projector is locked. During this time no other projector with the same name can be started. A running projector will update the lock timeout on every loop, except you configure an update lock threshold.
update_lock_threshold //Default: 0
If update lock threshold is set to a value greater than 0 the projection won't update lock timeout until number of milliseconds have passed. Let's say your projection has a sleep interval of 100 ms and a lock timeout of 1000 ms. By default the projector updates lock timeout after each run so basically every 100 ms the lock timeout is set to:
now() + 1000 msThis causes a lot of extra work for your database and in case the database is replicated this can cause a lot of network traffic, too.
Gap Detection makes projection to wait for upcoming events if any gap occurs in your event stream. To disable Gap Detection you can set value to