On Fri, Apr 17, 2009 at 10:44 AM, Rickard Öberg <[email protected]> wrote:
> But, what you describe is the first case I outlined: on ConcurrentException, > discard the UoW and do it all again. Just like how transactions work. But, > IF possible the user can choose to simply do refresh(), review the new > state, and then complete() again. Or, simply do a refresh() and complete() > automatically. This all depends on the specific usecase I think. You seem to have the notion that changes are direct human input. I would like to contend that this is just one of many minority cases (as I doubt there are any majority cases). For a mixed human-machine mutation, 'playing events' is not acceptable, and 'redoing everything' is annoying to the user. In the other post you mention; refresh(); vs merge(); So, let's talk about them for a second. refresh() in the currently proposed system can actually become quite an exercise. 1. BASE principle will dictate that reading the store is not necessarily going to resolve the ConModExc. 2. Reading through the /changes is a slow process and possibly very expensive (CPU and/or I/O). 3. Waiting for the read-store to get populated is slow, but not expensive. merge() is then suggested to be something that the client code can indulge itself in. The challenge then would be how to report conflicts, just like your regular SCM tool, and also keep the conflicts marked as such until resolved. IMHO, a blind merge() with auto-resolve is very dangerous, and hard to debug (intermittent problems in a runtime environment, and near impossible to replicate) and I would like it not to exist at all in such case. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
