To be honest, I'll have to admit that I rejected including the Cancel in my project. But I thought the problem was worth mentioning because it seems to say something about how RMI is conceived. My thinking was the following:
1. I'm considering cookies as sort of a "poor man's" transaction: lock a record, or set of records, for some sort of extended -- possibly web-based -- task. For example, on EDIT this would guarantee no one else can start a modify on the reserved record.
2 Once locked, user1 edits the record at their leisure -- maybe makes a telephone call to get a customer ID and gets lost in a conversation. Anyway, the edit might take considerable time.
3. Meanwhile user2 gets the idea to modify the reserved record. What happens? The software informs user2 that the record is in use (i.e. the lock interrogation option), and asks if user2 wants to forget the idea -- or wait on lock.
4. Say User2 isn't too busy and decides to wait for a lock. and wait. and wait.
5. User2 looks at his/her watch, and begins to wonder if
JAVA was such a good idea. User2 decides that the record was OK the way it was, and wants to cancel his/her request.
6. I think at this point User2 would begin to look for the PC's reset button. At least the 'X' on the frame.
This scenario has user2 cancelling his/her own access request, actually the record lock/reservation request. Clearly, User2 better not fuss with User1's locks, or User2 might discover more to be concerned about. But ... there's always a but ... the cancel infrastructure, if available, might also help the administrator on shutdown.
Long live Application Servers ...
Thx