Niclas Hedhman wrote:
This specifically means that UnitOfWork now truly is a record of changes,
and upon UoW.complete() these changes are sent to the EntityStore. The
EntityStore, if following BASE (not mandatory), simply validates the list
and stores the list of events, but does not apply it to the state. This
ensures that the changes are transactionally stored and the system is now in
an eventually consistent state.
Ok, so if I understand you correctly; In such scenario, the
EntityStore will upon complete() receive the 'state change list' and
after validation of its content can return immediately, and do the
'persistence' in background?
If so, wouldn't this need to be a configurable property, since most
users would expect something reported as saved not to be lost
afterwards in case of (for instance) power failure. I agree that for
many this is an acceptable compromise, but I wonder if it can be
consider 'always good enough'.
No no, when I say "store the list", it actually means transactionally
persisting it to disk. So the list of events is ensured to always be
there. Then the background thread can start applying events, or it can
be done on getEntityState(). If the thread fails it can restart later.
This is done by keeping two markers: one for last created event and one
for last read event. These two are also stored transactionally. Whenever
they mismatch there is work to be done before the state snapshot is up
to date.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
