On Thu, May 01, 2003 at 08:20:18PM +0900, Nico Hoogervorst wrote:
> Brian Candler <B.Candler / pobox.com> wrote in message news:<20030430212939.GB41345 / uk.tiscali.com>...
> > I am not sure about allowing one contact object to be shared between two
> > addressbooks though. Any change to the contact would have to be 'agreed' by
> > both addressbooks, which sounds like a fairly complicated two-phase commit
> > to avoid getting into an inconsistent state.
> 
> Not really complicated. Add Vetoable Change Support to the Contact
> class. The involved addressbooks register a Vetoable Change Listener
> at the contact objects. Whenever a contact is changed, all registrated
> listeners are allowed to vote about the change, and they can prevent
> that the change takes place.

I don't think that's sufficient. Other things could change in the period
between the go/no-go response and the requested change taking place, unless
you serialise everything.

An addressbook is not a particularly good example, but it can demonstrate
the point. Let's say that 'name' is the primary key and the only constraint
for an addressbook is that all objects it contains have distinct names.

    Address book A contains:  'fred' (shared), 'anne'
    Address book B contains:  'fred' (shared), 'bob'

Client X says to A "'I want to change name of 'fred' to 'jim'"
- address book A responds 'OK'

Client Y inserts another 'jim' into A

Client X asks address book B the same question
- address book B responds 'OK'

Client X changes 'fred' to 'jim' [*CONFLICT* reported by A]

Client Y inserts another 'fred' into A

Now X cannot rollback to 'fred' without also causing a conflict.

Like I say, not a particularly good example...

Regards,

Brian.