Hi, Thinking about this again, we would need MicroKernel.waitForCommit() only to detect changes written by *another* process (another cluster node). A process should be able to know what it changed itself, without polling, and having to ask the MicroKernel instance :-)
I was wondering if MongoDB supports feature to avoid polling. What I found is "Tailable Cursors": http://www.mongodb.org/display/DOCS/Tailable+Cursors http://www.shtylman.com/archives/217 So it seems a MongoDB MicroKernel could support such a feature. Whether or not this feature is needed (Jackrabbit 2.x doesn't have it) and whether this needs to be in the MicroKernel API is a different question. Regards, Thomas On 6/19/12 9:27 AM, "Thomas Mueller" <[email protected]> wrote: >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 >
