It extends the SimpleCommandBus, but dispatches commands asynchronously from the calling thread.
The solution is that events who's associated property returns null are not forwarded to any Saga instance. It is not possible to associate saga's with a null value.
The test shows that the GenericJpaRepository publishes events even if the aggregate doesn't have any state changes to store.
As described in issue #37. The GenericJpaRepository now checks for null values and aggregate with another version number than expected.
This deadlock could appear when a Saga dispatches a command which in turn publishes an event that invokes the same saga. The code in the Saga is executed using a lock on the saga. If the command cannot be executed directly in the UoW, the lock on the saga is released. If another thread is doing a similar operation, it may hang on the aggregate's lock, while keeping the lock on the saga. This issue is resolved by making sure a lock is held while the thread participates in an active UoW.
The SagaCache holds a weak reference to saga entries. However, a transaction holding a SagaEntry will not prevent the cached sage from being cleaned up. When cleaned up, it may be reconstructed without seeing the uncommitted changes held by the EntityManager. SagaEntry now holds a (hard) reference to the Saga being stored, to prevent cleanup while the transaction is running.
When an Event is published, the token is now guaranteed to be removed, even if publication results in an error.
Yeah, I know, it's a classical mistake. Sorry.
Probably due a race condition with the garbage collector, a value could be null, where not expected. Added loop until not null logic to prevent null values. (cherry picked from commit 1353b79)
The state change detection caused some problems in the following cases: - an aggregate was deleted - an aggregate contains entities, causing an inifinite recursion - the loaded aggregate was of another type as the stored aggregate This commit solves those issues.