but of course if two threads start moving around the same file pointer, things could get messed up. I've experimented with creating multiple RamdomAccessFile instances (for extra file pointers).
Originally posted by Titus Campbell:
If a read request for record 4 and a read request for record 5 come in at the same time, both operations should be able to execute concurrently right???
but of course if two threads start moving around the same file pointer, things could get messed up.
Reads and writes can happen concurrently: After all, only the writing Thread is 'moving' the file pointer.
Notice that both getRecord() and modify() methods of the Data class are synchronized, so although 2 records can be processed at the same time, only one record at a time will be actually read or modified. That of course assumes that all your clients (threads) use the same object that accesses the same instance of the file, -- and that's how it should be. I think it is a grave mistake to instantiate some other local copies of the file to make it "thread safe".
Originally posted by Eugene Kononov:
I don't think so, -- in the Sun's original code, all the read/write methods of the Data are synchronized. The getRecord() method does move the file pointer by calling the seek() method on the RandomAccessFile object.
Eugene.
[ October 02, 2002: Message edited by: Eugene Kononov ]
Yes and no. even though the methods on the Data class are synchronized, most of the better implementations of the SCJD that I've seen offer each GUI client it's own data class, by using a factory.
Originally posted by Eugene Kononov:
I am one of those people who offered each GUI client its own remote object, by using a factory, and I got a maximum score on my server design. And yes, my lock/unlock methods are NOT synchronized (there is no need, because they call synchronized methods of the lock manager). However, the key here is that all these remote objects should wrap the same instance of Data, and definitely the same instance of a lock manager.[/QOUTE]
I think I'm following your design, but it's seems a little round about. Maybe I'm not following you correctly. It seems to me that there is no need for the GUI clients to share a Data object: only that the Data objects themselves to coordinated thought a single shared instance-in your design, that would be the lock manager. I can't begin to speculate on why your extended tests failed without seeing the code: it may be a machine problem, or some other such. But if the locking is implemented properly, there is absolutely no reason (that I can fathom) why instances of the GUI should have to share instances of Data, that I can see.
Since the read/write methods of Data are synchronized, there is only one "read" or "write" allowed at a time. Yes, I can see a design where each remote object keeps its own copy of the Data, but this is a sure road to disaster.
Yes, but the fact that a given Data object is synchronized at the instance level has nothing to do with other Data objects(and, by extension, other GUI clients) being synchronized. It is certainly possible to a given Data object across GUI clients: I suppose that would work. But I don't think it's the better approach.
You only need to coordinate the Data object when you lock(for write activities): and since you are using a lock manager, that should be handled.
When you say 'Data', do you mean a data cache, or a Data object? I wonder if that's where we are missing each other. I mean a Data object: I do not recommend using a cache.
In fact, my first attempt to model the assignment was that type of design, and my testing revealed that given a sufficient number of simultaneous connections, this leads to unpredictable results in the state of the database. I would recommend this test to everyone:
-- create 20 threads (each thread representing a client), and have each thread repeatedly book 1 seat for the same flight, 100 times for each thread. If the seat count is reduced by exactly 2000 when all threads are done, you pass. I can guarantee that the design where the client connection keeps its own instance of Data will fail miserably.
It's a good test. I suggest 100 threads(because they are just as easy to create), and 100 is a nice, round number.
I should say that my own tests did not fail miserably, and that is possible to achieve the highest possible score in every category with such a design.
But perhaps you are referring to the design where each client has its own instance of Data for reading, but shares the same instance of Data with other classes for writing. That may actually work, but I think the associated complication will hurt the clarity of design.
Eugene.
[ October 02, 2002: Message edited by: Eugene Kononov ]
That is not at all what I mean, I mean a simple design, with a single Data object per client: for either reading or writing. In general, the lock method I advocate is very simple(only 13 lines of code, with comments), and the GUI clients are free to use the Data object without any gymnastics. And it has passed the 100 Thread test, several hundreds of times.
I'm curious. Do you know why your original design, with one Data Client per GUI client, failed?
All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ October 02, 2002: Message edited by: Max Habibi ]
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |