Originally posted by Qusay Jaafar:
Map m = new WeakHashMap();
is enough or am I missing something here.
How can I test this WeakHashMap() working.
I created two threads.
The result here:
SecondThread still waiting for record(7) to unlock.
is this senario for FirstThread is similar if the connection of a client as disconnected, (it seems not) or What? I think I need help here...
What about my second Question about Database lock?
Originally posted by Christian Garcia:
I decided not to implement lock/unlock directly in the Data class because it seemed (to me) more logical to include those functions in a server-side implementation. As far as I can tell, there isn't any reason to lock and unlock records on a local machine. In retrospect I doubt that is a valid defense of a design decision, but if you care to point out some caveats with it I'd appreciate it.
Since I last posted I took my design a step further. Now, I have a DataAccessFactory on the client-side and a ConnectionFactory registered with the RMI registry on the server-side. I use the DataAccessFactory to return remote or
local references of type DataInterface. This is achieved by calling an overloaded
getConnection() method that either takes a path to a local database or a String containing the server DNS and the registered name of the
ConnectionFactory in the RMI registry.
My RemoteDataInterface implements DataInterface which creates a nice "transparency" between local and remote instances. Essentially, when my
Controller creates an instance of the Model (the Data adapter) it has no idea where the Model reference came from only that it has one.
Thanks for your replies and for a great book.
Having two classes flagged as remote with one handing out instances of another doesn't seem at all correct. My best guess is to modify RemoteDataImpl to be a "regular" object and let ConnectionFactory take the roll of being "Remote".
Originally posted by Max Habibi:
I always bound the objects before returning them. That is, I had a private static int counter in the factory, and I used it to create unique names for the RemoteData objects. Thus, "RemoteData1", RemoteData2", and so on. I would then pass in each object's unique name to it as a member variable.
Thus, the close method on the RemoteData object would unbind it when the object was released. This way, you get the benefits of RMI controlling the life span of your object.
Originally posted by Qusay Jaafar:
Is this will solve the problem of a client who has a lock of a record and then crashed for any reason before unlock the record? I mean is the lock of the record will be released?
I read that using Unreferenced interface will not work while Client A which crashes and Client B blocks inside the server...
is that right? if it is, so what is the meaning for Unreferenced interface?
Qusay: Will you tell me please how I test this case by using a WeakHashMap?
Qusay: It seems using WeakHashMap is easier than using Unreferenced interface
The WeakHashMap will automatically remove the keys for you, but the downside is that it is done automatically: you are unaware of when it is done.
Whereas for Unreferenced, your code becomes explicitly aware that the client is dead, and can do any work you decide is necessary. The downside is that you have to do the work.
Now what happens in the following scenario: client 'A' locks record '1'. Client 'B' attempts to lock record '1' - it cannot get it, so it calls wait(). Client 'A' dies.
With WeakHashMaps, lock '1' will be removed the next time the garbage collector runs on the server. But client 'B' is still waiting to be notified - it could be waiting a long time.
Of course, you could get around this by changing the lock() method a little bit. But you may not be able to with the new assignment's instruction that the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked.
With Unreferenced, your code on the server gets notified that client 'A' is dead. You then have to unlock any locks that client 'A' held. As long as your unlock method calls notify then client 'B' will be able to continue.
By the way Max, I am quite impressed with your psychic abilities: you have a reply to Christian posted June 01, 2003 06:55 PM, in reply to his post sent 15 minutes after your response
Andrew: The WeakHashMap will automatically remove the keys for you, but the downside is that it is done automatically: you are unaware of when it is done.
Max: This is somewhat misleading, because when your code becomes explicitly aware of an Unreferenced is also automagic: thus, you are still unaware of when it's done.
Andrew: Of course, you could get around this by changing the lock() method a little bit.
Max: I don't at all agree that this is called for. It is, IMO, a bad idea to change the method signatures of the methods Sun provided.
The Unreferenced approach requires you to write code, while the WeakHashMap doesn't.
Max: But seriously, I know that Unreferenced is popular as a design choice for some good posters here, so I'm disinclined to disagree to0 strongly: to each thier own. However, in my humble opinion, it's not the best approach.
You learn how to close your eyes and tell yourself "this just isn't really happening to me." Tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton