Hi Bernard,
I've got several pointers on your question-set, but I find it hard to find the thread of continuity were you want to got with this.
So I'll just give some feedback, and please give me feedback on my response as well, so that we can come to a conclusion on this. :)
1) You say you assume 'an event for a saga is persisted in the saga-store'.
This is incorrect though. The SagaRepository stores the serialized version of a Saga. It does not store any events at all.
Hence you don't have to think about how that would work transaction-wise at all.
2) You ask if 'the transaction of the event creation also include the command sent by the saga'. This wholly depends on which components you use to set up your system. Are you using a Subscribing or a Tracking Event Processor? If you're using the Subscribing Event Processor, which `EventProcessingStrategy` are you using, synchronous or asynchronous? What type of `CommandBus` do you use to publish your Commands? The `SimpleCommandBus`, `DisruptorCommandBus`, `AsynchronousCommandBus`?
If we'd assume the default settings for everything, you'd have a synchronous `SubscribingEventProcessor` for you Saga, which will provide the Saga instance the event in the same thread which published the event (thus the active thread in your Aggregate). In the default set up, you'll also have the `SimpleCommandBus`. If you'd use that `CommandBus` in your Saga, it'll mean that the same thread which started the Saga (thus going back to the active thread in your Aggregate), will be the one publishing the command, but it'll also be the same thread starting up the following Aggregate to handle that command.
Transaction wise this is all handled by the UnitOfWork behind the scene, which in it's several phases will start/stop a Transaction. So if in the above set up we assume we're using the defaults, the transaction will be started by the first command publication, which will remain the same throughout the Aggregate's Event Publication, the Saga handling that and then the following command as well.
3) You ask why we cant set processing groups for our Sagas. That exact same question popped up on
Stack Overflow quite recently, from which a GitHub
issue was created. We're still discussing the pros/cons to this. If you've got any valuable input why we should allow Sagas to be set into Processing Groups just like Event Listeners, that would be much appreciated.
Hope this gives you some insights and as pointed out earlier, feel free to ask follow up questions based on my response.