• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

NX: Backing out of RMI operation

 
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Bob Reeves
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic