On Tue, Sep 9, 2008 at 6:28 PM, Rickard Öberg <[EMAIL PROTECTED]> wrote:
> Considering this, how do you feel that our > EntityStore.prepare/StateCommitter works? Is it good enough, or should > we specify more of the behaviour, in line with Jini Tx thinking? GutFeeling(tm) --> Since we don't have a case where we can do cross-ES commits, i.e. have more than one ES participating, the problem becomes a lot simpler. And I also think that the semantics we have saying that, if the prepare() completes, the commit() may not fail, is a extreme simplification of the Jini Transaction spec (in a single participant scenario). In reality, I think some/many/all of the ES implementations now existing are not totally committed to such semantics. I think we could have 2 people on this subject permanently to incrementally decrease the chances of fatal failures (i.e. data loss or inconsistent data sets). I need whiteboard and perhaps good company to think this thru, but the mentioned spec gives some insights to how complex such a "simple" topic really is. The Space semantics (if I have understood them) are pretty cool in that the entry has to be removed from the space, modified and put back into the space. If you don't own the entry, you can not modify it, and since the Space inherently doesn't have "identifiers" on the entries, it allows you to store multiple identical entries. That leads to some "interesting" implementation challenges for the EntityStore, since a "missing" entry means "write protected", but it needs to differentiate between "missing due to update in progress" vs "just not there". I doubt that the current GigaSpaces impl of EntityStore is correctly implemented with this aspect in mind. Cheers Niclas _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
