unlock Thread

[George Fung]

Should we implment a thread that will check the timout lock? Is it requirement in design and implmenation? I am doing Contractor assignemnt.

[George Fung]

I saw some posts discuss we should implment Unreferenced in server side. My data class has one object only. So, I register only one remote object. Then, how to detect died lock? If I use unreferenced, the server need to wait all client to dereference the remote data object. It seems can't solve the problem. SO, any idea?

[Mark Spritzler]

George, if you use the Connection design, where each client gets its own remote object from a ConnectionFactory that is bound in the RMI Registry, then the Remote Object for each client is the one that implements Unreferenced. This is a one to one relationship with the client, so if the client crashes. Then the Unreferenced method in the client's Remote Object will bethe one that calls unlock on all the records it has locked.
There is still just one Data class in that desing.
Mark

[George Fung]

Hi Mark,
Here's my understanding. Plz correct me if i am wrong.
For client, it will get remote reference from connectionfactory. Then, it will get remoet stub from server side.
In sever, I create a DataServer which will call Data class to acess database. In main method, I will regester a DataServer. So, there is one and only one DataServer Object. How can we create a multiple remote objects? We need to register many DataServer objects?
Thanks

[Mark Spritzler]

Actually George, you will include the stub in the client jar file. In order to receive the stub from the server would require dynamic downloading of the Stubs and requires a web server, which the assessors do not have.
The ConnectionFactory passes a new instance of your Connection class DataAccessRemote, this is the stub we are referring to above. This instance has a reference to the Data class, and LockManager (if using this elegant solution). There is only the ConnectionFactory bound to the registry. Nothing else is bound.
Mark

[George Fung]

Hi Mark,
Maybe I misunderanding the logic of RMI. Could you give me example (simple coding) of ConnectionFactory?
In server side, I regester the remote object once. For client side, every cleint has their dataaccesremote stubs. So, every stub belongs to new remote object of dataacessremtoe. right?
we implment datacccessremote interface. Everytime client disconnect the refercne to server, the server object will be notified. right?
Plz give me a sampel of coding of it? I am doing "Contractor" assignment.
Thanks you help, Mark.
George

Originally posted by Mark Spritzler:
Actually George, you will include the stub in the client jar file. In order to receive the stub from the server would require dynamic downloading of the Stubs and requires a web server, which the assessors do not have.
The ConnectionFactory passes a new instance of your Connection class DataAccessRemote, this is the stub we are referring to above. This instance has a reference to the Data class, and LockManager (if using this elegant solution). There is only the ConnectionFactory bound to the registry. Nothing else is bound.
Mark

[Mark Spritzler]

OK, I will post sort of Pseudocode.
ConnectionFactory Interface extends remote. It has only one method getConnection. It returns an instance of the DataAccess interface.
ConnecionFactoryEngine implements ConnectionFactory interface. It has a main method, this is the class that starts the server. In the main the registry is started, a single Data class and LockManager is instantiated and assigned to a static class variable. Then this class ConnectionFactoryEngine is bound into the Registry.
A client that wants to connect to the remote server, will lookup the ConnectionFactoryEngine the call the getConnection method, in the implementation of this method a New instance of a DataAccess class is instantiated and passed back to the calling client.
The implementation class of the DataAccess class will have extended Remote. So when an "instance reference" is passed back to the client, the client is actually going to use a stub. The actual instance of this class stays on the server and acts as the proxy for the client to calls to the server.
I hope that helps clear things up for you.
Mark

[George Fung]

Thanks your help, Mark.
So, there is one and only one DAta class and many dataAcess stubs. In each dataAcess stub, it will call methods in Data class. Also, DataAcess will implemnt unreference interface. Everytime client wnat to lock records, it will save the recordNo into array. When client disconnect suddenly, "unreferecne" will be called andunlock locked recodrs from recordNo array.
IT's my understanding. Is my flow okay?
Thanks,
George

[George Fung]

Hi All,
Also, is it required to use "connection Factory" design pattern? is it "must" requirement in old assingments? I am doing "Contractor" assigment, but it didnt' mention that every client has individual stubs. Could you quote the wordings of old assingmetn (e.g. FBN) that describe conenction factory. So, I can compare it and find out if it's "must" in my assingment.
George

[Jim Yingst]

Also, is it required to use "connection Factory" design pattern
I don't know about the other assignments, but no, it's not a requrement for Contractors, IMO. Many of us are using it for Contractors, mostly because it provides a convenient way to allow the server to clean up if a client is disconnected. However (a) this can be handled other ways, and (b) it's not clear that we're even required to handle client disconnects. The requirements never mentioned the possibility after all. But many of us think that client disconnects are something that should be handled by the system if possible, even if it wasn't mentioned. I think some people have mentioned that they didn't handle them, and they still passed. It's unclear how many points (if any) might have been lost for this.

[Jim Yingst]

So, there is one and only one DAta class and many dataAcess stubs. In each dataAcess stub, it will call methods in Data class.
To me, "stub" refers only to the class that will run on the client, which is generated by rmic. The client GUI calls the stub, which (through the magic of RMI) calls the DataAccess implementation on the server, which calls methods of the Data instance on the server.
Also, DataAcess will implemnt unreference interface. Everytime client wnat to lock records, it will save the recordNo into array.
If "it" is the DataAccess instance, yes. You may use an array or List - and if your assignment talks about "cookies" you probably need to save those too in order for DataAccess to unlock anything, so you probably will use a Map instead of array or List.
When client disconnect suddenly, "unreferecne" will be called andunlock locked recodrs from recordNo array.
Right. Though unfortunately "unreferenced" may not be called as quickly as we might like - it will be called eventually.

[George Fung]

Hi Jim & Mark,
It can solve the disconnect issues. how about solving dealock in cliend side?
Should we write a thread to check the time of locking? If the record is locked too long, we should unlock it automatically. Is it right?
Rgds,
George

[Mark Spritzler]

Originally posted by George Fung:
Hi Jim & Mark,
It can solve the disconnect issues. how about solving dealock in cliend side?
Should we write a thread to check the time of locking? If the record is locked too long, we should unlock it automatically. Is it right?
Rgds,
George

Well in the real world, yes you would want some way to not have deadlocks or handle them quickly. Luckily for us in the assignment waiting for Unreferenced to be called is sufficient to not lose any points.
The only way a deadlock can happen in lock is if a client locks a record and another is waiting and the original client never unlocks the record. With unreferenced the record will eventually be unlocked.
However, if you have a better solution that will work that isn't too complicated and doesn't recreate an already existing solution then post your idea and Jim will critique it.
Mark

[George Fung]

As you said, we should the requirement. As client is deveoped by us, it's not possible we only implment lock but no unlock. So, I think we don't need to handle it.
Maybe we make a thread to check if any record is locked too long.. It's a suitable solutoin

[Max Habibi]

Originally posted by Jim Yingst:
[QB But many of us think that client disconnects are something that should be handled by the system if possible, even if it wasn't mentioned. I think some people have mentioned that they didn't handle them, and they still passed. It's unclear how many points (if any) might have been lost for this.[/QB]

AFIK, no one has ever, lost points for not providing a lost key cleap mechanism. However, people have lost points for trying to go the 'extra mile' and providing an incorrect lost key disconnect mechanism.
A good solution to the disconnect issue is to use a WeakHashmap to store the client/key mapping. That's it, and forget it. The functioning is really pretty element. When the client disappear, then the key it's holding disappears too(that's the point of a weak hashmap). Thus, the record is freed up again.
All best,
M
[ July 08, 2003: Message edited by: Max Habibi ]