On Wed, Jun 22, 2011 at 7:18 PM, Rickard Öberg <[email protected]> wrote: > The "receiver" is a method in an interface. If this is defined by sender or > receiver is open really.
Ok, then maybe I misunderstood the general principle and looking a bit too much on the actuals. >> One part of the issue is that the EventStore needs to be part of the >> UnitOfWork scoping and commit. > > Yes! So, like we talked about before we need to look at the hooks in > before/after commit, and the semantics of that. Not trivial I think. I happen to get my event emits to be transacted by Hazelcast (almost by accident), from the fact that the Command objects from a Hz queue are wrapped in Hz transaction to survive JVM and HW failures, and events can only be emitted as part of commands, and state manipulation in EntityStore happens to be wrapped in the same Hz Transaction... But that is too much of 'coincidence' for my liking. >> I also see that the 'read events' are not required to be within UoW >> scope, as the events are effectively values, and need a different API >> and possibly even a different index/query system. > > The events are just stored in a log. If you want to index/query, that would > be a separate mechanism, which the EventStore could feed. There's an > infinite amount of things you might want to do with the events once you have > them in the log, but the log is the core. Yes. I wasn't saying that the index/query is part of the store, but as usual the indexer needs to interact with the store mechanism, and we should formalize any differences between event store and entity store. For instance, I feel that the 'range query' concept is so hard core, that it deserves special treatment for performance reasons. So, I would like to see an SPI being formed around that as well (or extending existing Query Expression API/SPI system). Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
