Re: Undo/redo implementation & JMI compliance

On Wed, Jun 26, 2002 at 04:11:12PM +0200, Svata Dedic wrote:
> Holger Krug wrote:
> > On Wed, Jun 26, 2002 at 02:44:17PM +0200, Svata Dedic wrote:
> > 
> >>There are two kinds of Listeners. So called pre-change and
> >>post-change ones.  You can store away object's properties when you
> >>get plannedChange() describing object deletion.
> > 
> > But is seems quite a heavy overhead for every
> > e.g. EVENT_ATTRIBUTE_SET to store away all necessary data to be
> > prepared for the case that the source object is deleted later on
> > in the same transaction.
> 
> BTW I was not talking about copy-on-write on every operation.

Think of the case when in one transaction first EVENT_ATTRIBUTE_SET
and then EVENT_INSTANCE_DELETE is fired. In the post-transaction event
handler even for EVENT_ATTRIBUTE_SET the object identity will not
available any more, when the object identity is determined by the
fully qualified name of its owning class proxy and the mofId of the
object, as now. OK you're right in so far that if EVENT_ATTRIBUTE_SET
and EVENT_INSTANCE_DELETE appear in one transaction, I do not need to
know the object identity, it's deleted anyhow. Hence I could check in
the post-change handler for EVENT_ATTRIBUTE_SET, if the object was
deleted in the same transaction. If yes, I can merge the
EVENT_ATTRIBUTE_SET with the EVENT_INSTANCE_DELETE and get the
identity from the former, where it was saved in the pre-change
handler.

> Can you please explain why lookup by MofID is so critical that it must 
> be implemented by JMI service ? I couldn't follow the path from 
> UndoManager functional requirements to this one.

As agreed above, Undo/Redo *can* be done without lookup by MofID. But
it would definitely be reasonably faster with fast mofId lookup. The
alternative is to access the class proxy using its qualified name and
scanning all instances owned by a class proxy for the one with the
right mofId. Furthermore Undo/Redo is not important for every type of
repository, but only for those used in interactive
environments. Normally those will be local caches like MDR and not
remote repositories. I think the Undo/Repo implementation is allowed
to formulate an SPI to be implemented by repository implementations to
be able to use Undo/Redo management. That SPI comprises JMI and adds
the repository interface with it's one method. I do not require to add
lookup by mofId to the JMI spec. But I require to provide services
above JMI to be able to use the Undo/Redo implementation. And this
services are trivial at least for MDR.

As far as short response time really counts for interactive apps that
should be allowed !?

-- 
Holger Krug
[email protected]