Robert Philip

Shivaji.
Hi. The assignment clearly states that the code in the data class has been written by a entry level programmer.
This should imply that the original synchronizations are not necessarily the best.

Here's a question : What is the advantage of having a multithreaded RMI Server if the underlying Database logic is single threaded ?
Cheers,
Robert.

My design is very straight forward and simple.
Only difference is I have implemented row-level locking instead of database level locking for every lock() that is called on the Data class.
Thanks Ian. Would love to hear opposing arguments against this design. Folks, Please join in.
Warm Regards,
Robert

Originally posted by Peter den Haan:
[B]....but also the file itself is not threadsafe, you need to single-thread access to it. Multiple Data objects (over the same file) are a big no-no.
- Peter
B]

Peter.
You are missing an important point here .... Only the read and write to one particular record is multithreaded. Add and Delete will have to single threaded. I have tested this logic on a quad cpu box with both linux and windows NT. Seem to work just fine.
Warm Regards,
Robert

Originally posted by Ian B Anderson:

If its RMI then you put 1 object on the rmiregistry and each client gets the same object how do you then assign them each an instance of Data. A connection class?
Ian

You could have a pool of remote objects which are assigned to clients on request.

Peter.
Yes if you implement a record level lock each region of the random access file is access by a single thread. I have seen this design in major applications accessing flat files.
Robert

Originally posted by Ian B Anderson:
Hello,
If you were using RMI then your Remote object would have an instance of data (just one instance used by all connections).
Ian

Not exactly, you could register the server with the registry instead of the remote object and call a factory method to create a new instance of the remote Object for each client.

Ian,
Two things, Locking can be implemented using a Singleton Lock Manager or hashMap even if there are multiple instances of data.
The object of the assignment is to implement a efficient locking mechanism. If there is only one instance of the data class, the server is effectively single threaded.
Secondly when you add or modify records you will use the lock database ( lock (-1) ) method so that modifications made by two threads do not interfere with each other.
Does that sound reasonable so far ?
Regards,
Robert.

My experiments with the random access file lead me to think that the random access file is thread safe if you allow only one thread to access a given record (via an offset).
I am inclined to use a new instance of Data for each remote connection that is granted to a client. If there is only one instance of Data , the db performance will be very dismal as only one client can perform operations on the db at one time.
This is not a "Record level lock". All comments are welcome.
No code fragments please. This is just an attempt to brainstorm and not cheat on the SCJD.

Re: http://hometown.aol.com/javalearners/promotion/index.html
There are no instructions on this website just more questions.
JavaRanch is a much better site... because it forces you to think and arrive at you own solution rather than pay some person a great deal of money to spoon feed a solution to you.
BTW : The SCJD is worth the money and time ONLY if you do the assignment yourself Otherwise it is just another piece of paper.

What LDAP server are you using ?
I had the same problem and I believe we have fixed it.

There is a good book that I shall recommend
Mastering RMI published by Wiley http://www.bookpool.com/.x/abdt2f76z8/sm/0471389404
Regards,
Robert

The Common Object Request Broker Architecture (CORBA) from the Object Management Group (OMG) provides a platform-independent, language-independent architecture for writing distributed, object-oriented applications. CORBA objects can reside in the same process, on the same machine, down the hall, or across the planet.

The RMI Specification does not guarantee every request to be handled in a new Thread. Existing threads could be reused to service more than one request.

You have answered your own question.
This behavour is because you have not instantiated the security manager.
Regards,
Robert

There is a good book that I shall recommend
Mastering RMI published by Wiley http://www.bookpool.com/.x/abdt2f76z8/sm/0471389404
Regards,
Robert