Win a copy of Java 9 Modularity: Patterns and Practices for Developing Maintainable Applications this week in the Java 9 forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

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

Larry LeFever
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!