Win a copy of Succeeding with AI this week in the Artificial Intelligence and Machine Learning forum!

Nico Vanoppen

Greenhorn
+ Follow
since Mar 22, 2002
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Nico Vanoppen

Hi everybody,
I've been reading thru a lot of postings on this forum and finally I've come to a design that satisfies me. I used the connection factory implementation, which has been the subject for about a zillion times on this forum
In a nutshell :
DataInterface
-------------
extends Remote
contains all public Data methods
RemoteDataImpl
--------------
extends UnicastRemoteObject implements DataInterface
wraps Data
contains reference to Lockmanager
LocalDataImpl
-------------
implements DataInterface
wraps Data
RemoteDataFactoryImpl
---------------------
RMIregistry bound
extends unicastRemoteobject implements RemoteDataFactory
returns RemoteDataImpl objects that contain a reference to an unique Data object
Data
----
just minding it's own business
Server
------
binds RemoteDataFactoryImpl to the registry
LockManager
-----------
Guards the locks
DataProxy
---------
this is the client's gateway to the data
implements DataInterface
2 ctors : local - remote
Now, I'm having troubles choosing the righ packages for these classes. I tried the following
suncertify.client
-----------------
DataProxy
LocalDataImpl
suncertify.server
-----------------
Server
LockManager
RemoteDataImpl
RemoteDataFactoryImpl
suncertify.db
-------------
Data
classes provided by Sun
suncertify.common
-----------------
DataInterface
RemoteDataFactory
I try achieve that a client only needs suncertify.client + suncertify.common, and that a server only needs to import suncertify.server + suncertify.common, but I'm not sure if I'm sticking to the requirement that

Any additional classes you create that are related to the database should be placed in the suncertify.db package

with this. I'm also not sure (yet) that a client doesn't need to import the suncertify.db package...
Any suggestions ?
Thanks
Hi there,
Thanks guys for pointing that out, you ( almost ) convinced me to follow your technique
Thanks !
Xiaoma,
Is this the only reason you work with a connection object, namely to assure that no client can unlock another client's lock ?
If so, it looks like overkill to me, returning a long on and passing this same ID to seems so much easier to me
Of course, changing the signatures is needed, but is this so a bad idea ?
I'm still not convinced of the need for a connection object
Thanks,
Nico
Mark, thanks for explaining.
I also have thought about this but reasoned that since the client deals with the remote INTERFACE of the Data class we could change it's implementation without altering client code. If your implementation changes mean also changing the interface, then ofcourse changing the client code is necessary. But I suppose using a real database instead of db.db won't do this, will it ?
Thanks,
Nico
Mark,


So by binding the Data class into RMI, you have to rely more on that Data class to handle more things. First you have to change the signatures of all the methods, and also have it extend UnicastRemote. Not really a good design there.


Can you give me an example of one of those more things that the Data class must take care of when using my idea of design because I can't bring one to mind.
I suppose that it's for these extra tasks you would alter the signature of de Data class
Ain't extending the UnicastRemoteObject sexy enough
Nico
Hi there,

1. if all the methods are syn. then why we need use of HashSet in lock/unlock?
2. in any case, if object is same and all the methods are syn. then operating on single record means blocking all the threads or you can say locking all the db operations.


1.Look what happens if you don't use lock()-unlock() :
Suppose the number of available seats in a record is 10 and that client A and client B are both willing to alter this record. Since A is first it will block the Data object by reading in the record in a synchronized manner, so B has to wait its turn. A reads that there are 10 seats available and releases the Data object while exiting the synchronized method. Now B gets permission to read. B also reads 10 available seats. Suppose that while B is booking f.e. 3 seats A has finished booking 2 seats writing the updated record, again synchronized. By now, B wants to write its altered record but has to wait 'til A has finished. Ok, A has finished leaving 8 seats available. Now B gets to writing the altered record still assuming there were 10 seats available and ending up with 7 available seats instead of 5.
So you need a mechanism to avoid that between reading and writing no other thread can interfere.
2.I totally agree this but I'm still not sure if this statement is correct.

Nico
Hi there,
If you place the loop inside the lock() method you don't need to alter the signature :

where is some Collection. (I've made an abstraction of primitives and objects in the privious snippet of code.)
When you return from the lock()method you're sure the requested record is locked.
Don't you think that making the modify()-method synchronized will block the collection for other threads, as I priviously stated ?
Nico
Hi there,
Thanks for your reply !
I think your "loop solution" will easily solve this problem but I don't understand why you should change the return type of the lock method; as it returns the lock is achieved, isn't it ?
Another question flashing thru my mind : If modify() is synchronized, won't this mean that you never can have more than 1 element in the hashset ? The first thread who can place it's record number in the set will block the Data object by calling the synchronized modify method and thus prevent any other thread to even invoke the lock() method.
Please correct me if I'm wrong..
Oops,
accidently sent my message.
As I was saying :
I can't figure out how to manage this.
Please correct me if I'm wrong :
Before you can call wait() you'll have to own a lock on an object, right ?
Which object ? The Data object ? If so, you have to wait until no other thread is reading, writing, modifying ... using the Data object, because all these methods are synchronized. Doesn't seem very efficient to me.
Besides that, if the record number isn't in the set of locked records, you're locking the Data object for all other threads, right ? I think we shouldn't block the way for threads that are interested in other record numbers, should we ?
I think if we work it out this way we shouldn't bother lock/unlock because the hashset assures us that no other thread is treating the record we're interested in...
Should'nt we provide an object per record (some sort of ticket) on which we can apply the wait()-notifyAll() combination ? In this case we're not blocking threads that are interested in other records.
As you probably can see, I'm not that strong in threads, but I'm just giving you my thoughts.
Hope to read a reaction soon, thanks
Nico

I don't think using a file is a very elegant way of doing this. Personally, I plan on using one of the containers in the Collections API in java.util. I haven't decided yet but am considering HashSet. You could then check to see if your Collection already contained a lock on the requested record and if so you could wait() for the lock to be released. Of course everytime a lock is released, you'll need to notifyAll().


Hi Michael,
I was also thinking about solving this issue with a wait()-notifyAll() combination but I c
Hi there,
Sorry, but you've lost me. I'm also working on the SCJD exercice and I approached that problem like this : let the server instantiate the Data class just once and register this object with the rmi-registry. Clients requesting the Data object all receive a remote interface whose methods "invoke" the methods of this one object. I don't understand the need of "connection objects" to solve this problem.
Greetings
Nico
Hi there,
Maybe I don't understand your problem but when you are using RMI, don't all the clients get a reference to ONE SAME OBJECT, namely the one that your server registered with the RMI-registry ? If so, your problem doesn't exist, does it ?
best regards,
Nico