Hi, >>- We can implement the polling approach (using a 0 timeout) but also have >> the option to do blocking. Since this can be directly delegated to the >> Microkernel (waitForCommit) the added complexity for this is minimal. > >The complexity is still there, it's just one level below. Personally >I'd rather drop the waitForCommit() method unless we really do have a >hard use case for that functionality.
I believe waitForCommit() actually simplify things. It's not a hard use case, but from an architectural point of view the advantages of waitForCommit() are: - no need for polling, and configuring polling frequency - no need for callbacks - events are delivered as early as possible With polling, beside the obvious disadvantage that events are delivered (possibly a lot) later, polling also needs more CPU cycles, specially when there are multiple consumers. Also, because of the delayed event delivery, cache efficiency is reduced, further deceasing performance. Regards, Thomas
