aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: Backing out of RMI operation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX: Backing out of RMI operation" Watch "NX: Backing out of RMI operation" New topic
Author

NX: Backing out of RMI operation

Bob Reeves
Ranch Hand

Joined: May 01, 2003
Posts: 64
Is there a straightforward way to cancel an RMI operation in progress? The ability to backout seems quite useful, but unduely awkward to imnplement.
Thx
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Hi Bob,
before we start down this road, why are you considering this? That is, can you justify your reasoning for poviding this level of support, in light of the assignment?
M


Java Regular Expressions
Bob Reeves
Ranch Hand

Joined: May 01, 2003
Posts: 64
Hi Max,
I agree that this isn't absolutely necessary. But, my assignment has this extended record reservation capability, i.e., cookies. A user may hold the cookie for an indeterminate period while they do an edit or whatever. Thus, if another user were to want to lock the record while user1 (who holds the cookie) was having lunch -- well, it may be nice to allow an operation cancel option. I am using timeouts on my cookies, and an "is locked?" interrogation capability, but still a real system would need a cancel option. I see this as involving new threads on both the user and server machines, and the use of InterruptedException. I don't like this type of approach.
Thx
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
How would the cancel operation work? Who would initiate it? User1, who has the cookie? User2, who needs it? A system admin? Or would it be automatic?
M
Perry Board
Greenhorn

Joined: May 03, 2003
Posts: 29
I had a similar thought but didn't know how to do a "cancel" so I haven't implemented it. (probably won't anyway, but am curious.) I was figuring the way it would work is:
1. Client A holds a record lock and forgets about it (goes out to lunch) or his computer crashes, leaving the record in a locked state.
2. Client B tries to acquire the same record lock. The thread blocks while waiting for that lock, which could be indefinitely, so the client's RMI method call is "frozen" while waiting for a response.
3. Client B's gui (which runs in a different thread than RMI calls) has a cancel button to give up trying to get that record.
The question is, what does the cancel button do? How can an RMI call be canceled? Seems like it might need to sort of "terminate" a thread. Is this even possible?
Bob Reeves
Ranch Hand

Joined: May 01, 2003
Posts: 64
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
Bob Reeves
Ranch Hand

Joined: May 01, 2003
Posts: 64
Hi Perry:
Sorry, I didn't see your post when I responded.
I followed the same logic you outlined, but put a task supervisor on the server (ie. the remote object). The supervisor started the database access threads that do the work, blocking the user RMI call until the worker thread completed. Then add a method on the supervisor for cancel that takes a user ID, maps it to a worker thread, and I think we can cancel. The cancel is the generation of an InterruptedException on the worker thread. The server code must follow the InterruptedException guidelines pretty closely for this to work. This approach didn't seem too straightforward, so my original post.
My conclusion is that RMI is not a good choice if one wants to cancel.
Thx
Perry Board
Greenhorn

Joined: May 03, 2003
Posts: 29
Ahh. I can't say I know the proper way to use an InterruptedException, but that sounds like a decent plan.
How about this idea, too (new scenario here, I have hotel assignment, by the way):
1. Client performs a search but leaves search criteria blank to retreive all records.
2. Search indicates that 20,000 records were found. They begin to be retrieved one by one (progress bar creeps along).
3. User says, ugg, I don't want that many records. Clicks cancel, which sends InterruptedException to his own client thread that is downloading each record.
4. User adds search criteria to perform a new, limited search.
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
I think the approach is sound, and probably should be done in a commercial application, where the goal is functionality. This is a reasonable architectural approach, and indicates strong professional tendencies.
However, I don't think that this level of resilience is necessary for this assignment, and may even be a determinant to your score. Because the goal here is following directions, and code to specs. The project didn't ask for this, and I don't think they want it. That is, I don't think Sun is looking for the most failsafe solution: I think they want to be able to affirm that you can code to specifications, and don't overreach, and follow reasonable paradigms.
JMO,
M
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: NX: Backing out of RMI operation