File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes re: compatibility with test harness --  lock(), unlock() Big Moose Saloon
  Search | Java FAQ | Recent Topics
Register / Login
JavaRanch » Java Forums » Professional Certification » Developer Certification (SCJD/OCMJD)
Reply Bookmark "re: compatibility with test harness --  lock(), unlock()" Watch "re: compatibility with test harness --  lock(), unlock()" New topic
Author

re: compatibility with test harness -- lock(), unlock()

Larry LeFever
Greenhorn

Joined: Jun 13, 2000
Posts: 18
It seems pretty silly (and unrealistic) to have the client-app make discrete calls to "lock()" and "unlock()", especially if RMI is used (issue: granularity of remote methods).
Partly in the interest of ensuring Sun's test harness will work properly with my solution, I'm consequently planning to implement "lock()" and "unlock()" so as to effectively be no-ops unless a private flag is set indicating that the caller is one of the update-related methods (of the Database class).
That is, the implementation of, e.g., "updateRecord()" would set such a flag as "doLock"; and, in the local case, "lock()" would actually do the locking, while, in the remote case, the remote "updateRecord()" method will have been called so "lock()" will be called only on the server-side.
This way, each, e.g., server-side, thread would be responsible for calling "lock()" and then "unlock() within each update-related method, so the server-side wouldn't need to keep track of which client has the lock on which record, since each would have to "wait" and asynchronously poll for that lock, regardless of which server-side thread was last to set it.
(Incidentally, I'm also planning to implement the lock with the help of a third value for the status-byte that's at the beginning of each record: "locked" in addition to "live" and "deleted"; and, of course, I'd bitwise-OR "live" and "locked" as needed).
And I figure I'll use that idea I just saw mention of on this discussion-board, regarding running, periodically, a kind of lock-garbage-collector thread.
However, it occurs to me just now that, using my strategy as described above, records would be left improperly locked only if the server crashes, since its a server thread that would be running any given update-method, which would be handling both locking and unlocking in the context of that one method.
I'm pretty confident this strategy will work, but I'm not so confident it will be compliant with Sun's test harness.
Any thoughts?
------------------

Sun-Certified Java Programmer
 
 
subject: re: compatibility with test harness -- lock(), unlock()
 
Threads others viewed
why lost so many points on locking
RMI confusion
Take this Testing Tool for Data Class
NX: Client side lock vs Server side lock
Concurrency issue with create(...)/createRecord(...) [URLyBird]
developer file tools

cast iron skillet 49er

more from paul wheaton's glorious empire of web junk: cast iron skillet diatomaceous earth rocket mass heater sepp holzer raised garden beds raising chickens lawn care CFL flea control missoula heat permaculture