James: 1) What thread death scenarios are we talking about here? Exceptions on the server side? Client disconnections
Jim: Client disconnections, mostly. At least, that's the part you have least control over from the server.
James: 2) Couldn't this problem be handled soley by finally blocks?
Andrew, vaguely recall you quoting a Wiki Web principle of you aren't gonna need it. Looking at your arguments for client side locking, most of them are based on, 'at some point in the future'.
I noticed that when you completed the assignment Andrew you scored 58/80 for locking
was this using client side locking or a more (how to phrase) server-side solution?
Been trawling through the forums a bit more on this issue. I think that the UrlyBird 1.3.1 has different requirements on the locking than the contractors. My DBMain interface has no client id cookie element to it on the lock() and unlock(), just a record number. This implies to me that other assignments might require client side locking, but that its beyond the scope of my version of UrlyBird.
btw just returned to the UK from 7 months in Oz, including about 5 trips to Sydney
What's a manly ferry? Is it anything like a manly fairy?
Moreover, our customer has explicitly requested a design that will make future enhancements easier, so there is some justification for making consideration for those future enhancements part of what you do need now.
The IT director does not anticipate much reuse of the first Java technology system, but intends to use that system as a learning exercise before going on to a web based system.
Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs.
What is the purpose of isLocked(int recNo) method ? I cannot figure out where to use it.