Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above. You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.
Fernando Franzini - Java Blog
I'm not quite sure what you mean with a lost lock.
Fernando Franzini - Java Blog
I mean that client dont matter how (call direct or use service layer or whatever) lock one record and somenthing happen that interrupting process and so this record end up blocked forerver in server.
Cheers, Roberto Perillo
SCJP, SCWCD, SCJD, SCBCD
call notifyAll() instead of notify()
Fernando Franzini - Java Blog
Fernando Franzini wrote:I'm used RMI + ServiceLayer...so is Thin Client..right ?
Cheers, Roberto Perillo
SCJP, SCWCD, SCJD, SCBCD
Fernando Franzini - Java Blog
Fernando Franzini wrote:In my case...is "on the server side".....e.g. the client just receive RMI proxy reference and call methods by remote interface and all processing is being done in server.
Cheers, Roberto Perillo
SCJP, SCWCD, SCJD, SCBCD
Fernando Franzini wrote:Hi Folks
My assignment say :
Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above. You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.
So I implemented lock properly (at least I hope so ) with wait(), notify() and another stuff....and I've decided ignore completely everthink about managed lock lost...I mean that I dont care if this will happen......I just will document in my choices.txt....cause the assignment dont say nothing about that.....
So...someone have some opinion ? Or submit the assignment with this option ? It's ok ?
Another questions is about RMI....I've decide use it....so.....if I dont care about 'lost lock' I dont need implement RMIFactory (like Monkhouse book explained about) to managed thread and identify threads owner about lock bla bla bla......? I'm confused
Regards.
SJCP 1.4 & 6.0 | SJCD | OCEJWCD | Oracle Certified DB SQL Expert
Therefore, if the client "dies", "hangs" or "freezes" after the request is initiated, there will be no "lost locks", since it's all handled on the server side. Now, if the business layer dies in the midst of processing a request... well, then chances are the data access layer died as well and all server components will have to be re-initialized (so, no lost locks because we start "clean").
Fernando Franzini - Java Blog
Create symphonies in seed and soil. For this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|