Before attempting to acquire a lock, the thread checks whether the lock is already owned by a thread waiting for a lock owned by the current thread. If that is the case, the lock is not acquired and a DeadlockException is thrown. This will release the other locks, giving the other thread the opportunity to acquire the lock it was waiting for and continue processing. The failed operation can usually be retried automatically. Issue #AXON-13 add Fix versions 1.5
Fixes issue #60. Due to the fact that the responsibility of extracting snapshots lies in the repository, the use of the SpringPrototypeEventSourcingRepository is mandatory. The standard EventSourcingRepository with a SpringPrototypeAggregateFactory will not suffice.
It seems that, under high load, Hibernate sometimes tries to insert an Entity, instead of updating it. By making an explicit query, we can prevent this.
The UnitOfWorkListener.onPrepareCommit method was not given the entire list of events to be published. Instead, only the events that had been directly registered for publication through UnitOfWork.publishEvent we in the list. The fix ensures that all events that will be published on any EventBus on UoW commit are contained in the eventsToPublish list. See also: https://github.com/AxonFramework/AxonFramework/issues/52
The BeanPostProcessor will detect Java Proxies and inspect the actual bean instead. Where possible, the proxy is invoked. In other cases, method invocations are redirected to the target of the Proxy. This includes some updates of library versions. (cherry picked from commit b7066bb)
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.
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.
Merge branch 'axon-1.x' of github.com:AxonFramework/AxonFramework into axon-1.x Conflicts: incubator/mongo/src/test/java/org/axonframework/saga/repository/mongo/MongoSagaRepositoryTest.java incubator/mongo/src/test/resources/META-INF/spring/mongo-context.xml
…t test for saga repository
Yeah, I know, it's a classical mistake. Sorry.
…o Mongo instance is running