Marcus Rohrmoser edited this page Mar 29, 2011 · 1 revision

Table of Contents


Linear Single-User

The swing package javax.swing.undo brings a rather easy to implement undo/redo support.

Though the Sun Tutorial is targeted mostly at text documents, it also works fine for graphics.

See the current JCurlShotPlanner for an example.

Non-Linear Single-User

If the user can pick items to undo/redo from a command history the undo mechanism is called "non-linear" or "selective"<bibref>Berlage1994</bibref>.

This can't be implemented with javax.swing.undo the out-of-the-box If the user should get a command history and be able to pick undos und redos we need more than Swing UndoManager, because

  • a list of all edits must be displayed (which is package private).


A common problem to all multi-user undo strategies is


Any multi-user application has to integrate all users' contributions into a consolidated "common" command history, be it centralised in one repository or distributed and redundant at multiple or all users' clients.

The solutions include

Shared Memory

Does make no sense in this context (JCurlShotPlanner) as the clients usually run on separate hardware

Floor Control

Manages one exclusive, typically coarse grained lock, i.e. blocking any interaction from every user but the lockholder. This is not desireable as it

  • drastically degrades the responsiveness of the application,
  • is overly restrictive (for JCurlShotPlanner), as the 17 primary entities (16 initial rock positions plus shot target and speed) should be modifyable independently,
  • still requires conflict resolution for mid-air collissions (aquire lock).
See also the introduction of <bib>Munson1996</bib><bibref>Munson1996</bibref>.


See <bib>Munson1996</bib><bibref>Munson1996</bibref>.

Linear Multi-User

Doesn't make much sense, as a user might want to undo a remote change but keep a local one.

Non-Linear Multi-User

Situation: exactly what Chapter 2.5 "Undo in Multi-User Applications"<bibref>Berlage1994</bibref> analyses. That's what Collaborative Editing should aim for.



The desired solution for Collaborative Editing should have those characteristics:

  1. applicable for two or more users,
  2. high latency (WAN) tolerant,
  3. low bandwidth usage,
  4. minimal number of events,
  5. minimal locking,
  6. high responsiveness,
  7. support long running, session like edits (e.g. mouse drag operation),
  8. support short running, atomic edits (e.g. undo/redo operation),
  9. automatically resolve mid-air collissions in an way obvious to the user.


  • optimistic or no locking (because 2., 5., 6.),
  • no ACK but only failure responses (stay optimistic),
  • non-mandatory "in edit" messages at the begin of a drag (mostly to support visual feedback and reduce mid-air collissions),
  • a common virtual time<bibref>Ellis1989</bibref> (maybe a Lamport clock suffices?) and timestamped messages (for a common edit history),
  • selective multi-user undo to support both global and local undo (Chapter 2.5, <bibref>Berlage1994</bibref>),
  • message bookkeeping (numbering) to detect lost messages,
  • prioritised users (or: session participants) to resolve mid-air collissions automatically.
Chapter 6, "Synchronous Cooperation"<bibref>Berlage1993</bibref>.

Once more than two users communicate, a Lamport clock will not suffice to resolve all conflicts? If all messages are broadcasted to all users it will suffice in combination with user priorities to resolve simultaneous edits.


Read papers are <bibref>Berlage1993</bibref> <bibref>Berlage1994</bibref> <bibref>Munson1996</bibref> <bibref>Lamport1978</bibref>

Next come <bibref>Mattern1989</bibref> <bibref>Choudhary1992</bibref> <bibref>Kurlander1988</bibref> <bibref>Prakash1992</bibref> <bibref>Prakash1994</bibref>



You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.