Multiple instances of Data.

[Robert Philip]

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.

[Ian B Anderson]

Hello,
I don't think you should be using an instance of Data for each remote connection. If you did how would you implement locking? Each instance of Data wouldn't know about the other Data classes etc.
If you were using RMI then your Remote object would have an instance of data (just one instance used by all connections). Also forget performance issues with regards to this assignment, you would never use a flatfile normally, its just theory for the assignment.
When you put an object on the rmiregistry all clients would lookup and bind to the same object.
Hope this helps
Ian
[This message has been edited by Ian B Anderson (edited November 06, 2001).]

[Robert Philip]

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.

[Robert Philip]

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 B Anderson]

Hello,
Yes it would be possible to implement locking using multiple instances of Data but why would you want multiple instances of data. (Also the locking would be complicated and it would be hard to make threadsafe across multiple instances. What if 100 users connect, 100 instances etc)
I may have missed something but I still don't see why you would need multiple instances of Data? You say its for performance but I don't see how it would work.
What is your network approach going to be?
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

[Peter den Haan]

Originally posted by Robert Philip:
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).

True, as stated - but not the way you mean it Not only the File object, 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
[This message has been edited by Peter den Haan (edited November 06, 2001).]

[Robert Philip]

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

[Robert Philip]

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.

[Robert Philip]

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

[Ian B Anderson]

Hello,
I wish you good luck then.
But only 1 thing... In the spec it says something along the lines of "a design that is understood by junior programmers will be prefered to that of a complex one even if the complex one is more efficient".
But Good luck.
Ian

[Robert Philip]

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

[Shivaji Bhosale]

My design is congruent with Ian's, where I register single instance of Data to the registry. To identify the clients i am generating id's like session id's.
While I lock, unlock or modify a record, I check, record number already in the Hash of locked records or not ?
Only problem so far I had untill 3 days back was, I was using Hashtable instead of HashMap.
Whatever Robert says seems to be logical that having multiple instances of Data class performance will be higher. But as I can see from given code by the exam authority, the functions which actually deal with Database file for reading & writing are themselves synchronized.
So my natural choice went to having single instance of Data class, as well personally I find this approach trivial.

[Shivaji Bhosale]

My design is congruent with Ian's, where I register single instance of Data to the registry. To identify the clients i am generating id's like session id's.
While I lock, unlock or modify a record, I check, record number already in the Hash of locked records or not ?
Only problem so far I had untill 3 days back was, I was using Hashtable instead of HashMap.
Whatever Robert says seems to be logical that having multiple instances of Data class performance will be higher. But as I can see from given code by the exam authority, the functions which actually deal with Database file for reading & writing are themselves synchronized.
So my natural choice went to having single instance of Data class, as well personally I find this approach trivial.

[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.

[Peter den Haan]

Originally posted by Robert Philip:
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.

Ok, I did my homework this time and take back what I said. The important point is that RandomAccessFile is completely unbuffered; every read() or write() is directly translated into a kernel call. One would hope that a kernel handles this correctly (although as you note concurrent access to the same record certainly is not handled correctly). I am no longer convinced that this approach is thread-unsafe but, in the absence of decent documentation, I am not convinced that it is threadsafe on all platforms and JVMs either.
The fact that the technique is used in major applications is hardly a reassurance; double-checked locking is widely used yet it doesn't work in the general case.
- Peter

[Kalichar Rangantittu]

Can more than one RandomAccessFile access a file system file at the same time? I have multiple instances of Data, ie, 1 Data perconnection and dont want to make it a single instance. Is this safe or not? Can someone please point me to relevant documentation?

[Kalichar Rangantittu]

Consider for example the code shown below:
public class RaTest {
public static void main(String args[]) {
Accessor a = new Accessor(10, "A");
Accessor b = new Accessor(29,"B");
a.start();
b.start();
try {
a.join();
b.join();
}
catch (Exception exp) {}
}

static class Accessor extends Thread {
int count;
String name;

public Accessor(int count, String name) {
this.count = count;
this.name = name;
}

public void run() {
try {
RandomAccessFile ra = new RandomAccessFile("test.txt", "rw");
while (true) {
int read = ra.readInt();
System.out
.println("Thread READ:" + name + ":"
+ read);
ra.seek(0);
System.out.println(" Thread WRITE:" + name

+ ":" + count);
ra.writeInt(count);
ra.seek(0);
}
}
catch (Exception exp) {
System.out.println(exp);
}
}
}
}
I ran this on windows/unix multiproc environments and there were no problemns. All the program does is write a single integer to the 0the position of a buffer. Any comments???