Forums Register Login

Multiple instances of Data.

+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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).]
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
 

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).]
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
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???
Seriously? That's what you're going with? I prefer this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 1011 times.
Similar Threads
lock & read or just read?
URLyBird 1.3.1 DB Access layer design, pls comment!
B&S Locking Strategy
Confused on synchronization of RandomAccessFile
Locking(MaxExample and SunProject)
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 14:09:03.