Multi-Commands in one Transaction and CachingEventSourcingRepository

Imported from Google Groups
1

Hi!

I saw Allards hint that that Multi-Commands in one Transaction is sometimes the most pragmatic way to solve some problems:
https://groups.google.com/forum/#!searchin/axonframework/are$20multi$20command|sort:relevance/axonframework/M8SlGXsUsjM/af4QU8FgkOwJ

What I’m not quite sure about is: Does the CachingEventSourcingRepository respects the running Transactions
and does it Cache only Aggregates which transaction has been committed?

Regards,
Dirk

2

Hi Dirk,

the CachingEventSourcingRepository generally keeps the aggregates in memory (otherwise, it wouldn’t be much faster). While an aggregate is being used, there is a lock preventing other commands from modifying it (in another thread). If a unit of work is rolled back, the cache entry is evicted to ensure that new commands will not be executed against an erroneous version of the aggregate.

So I guess the answer is yes.
Cheers,

Allard

3

Hi Allard,

ok, but if I have one thread doing something like:

tx.begin()
issueCommand1()
issueCommand2()
tx.end()

Another thread could see the state after issueCommand1() because there is no Aggregate-Lock for the whole DB-Transaction tx.
Only for a single command. Or do i miss something? Do I need to manually Lock the Aggregate using the LockFactory right after tx.begin()?

cu,
Dirk

4

Hi Dirk,

it’s not recommended to manage a transaction around multiple units of work. In that case, it is best to start a unit of Work (using DefaultUnitOfWork.startAndGet(…) ), then start a transaction, and have the onCommit() and onRollback() of your newly created UoW invoke the commit and rollback of your transaction.
Note that a UnitOfWork requires a message. You could provide null.

By wrapping the UoWs into another one, you guarantee that locks are kept until the outer unit of work has completed.

However, do note that handling multiple commands in a single UoW is a design smell. It’s an indication that -possibly- consistency boundaries aren’t defined correctly.

Cheers,

Allard

5

I could wrap this logic into a new Command. I didn’t have done this till now, because I would prefer to have the logic into my Anti-Corruption Layer and not in the CommandHandler.
But maybe, as you pointed out, the latter would be the better choice then.

6

Hi Dirk,

I’m not sure if I understand your argument of the AC Layer and the CommandHandler. The code you sent earlier, is that something you’d have in the Anti-Corruption Layer?

Allard

7

Hi Allard,

yes. We haven an Aggregate which lives a whole day. And after 17 o’clock, it will get reconstructed.
This is done by the ACL. The ACL accesses a lot of legacy systems and issues a lot of commands to reconstruct the aggregate.

And we would like this logic to happen in an atomic fassion. So that no client sees the aggregate “under construction”.
I think I could wrap this logic into a single “Reset”-command, but I would love to have this logic into the ACL, because my aggregates business logic
shouldn’t care about this process.

So it feels wrong for me to put it into the aggregate. Or what is your opinion about that?

cu,
Dirk