A clear design, such as will be readily understood by junior programmers, will be preferred to a complex one, even if the complex one is a little more efficient.
Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above.
Jacques<br />*******<br />MCP, SCJP, SCJD, SCWCD
Originally posted by Jacques Bosch:
Reads and writes on my raf obviously have to be synchronized to prevent data corruption. But if I don't use a cache, writing and reading directly from the raf, only one client can ever perform a read/write at any one time, because of the synchronization on the raf. Even if two clients are updating two different records, one will have to wait for the other to finish.
Regards, George
SCJP, SCJD, SCWCD, SCBCD
Originally posted by George Marinkovich:
For this, you need a record locking mechanism. If you [1] lock the record, [2] read the record, [3] update the record, and then [4] unlock the record, then the scenario in the first sentence of this paragraph cannot occur. From the point of obtaining the lock on the record until you unlock the record, you have exclusive hold on the record in question from all other clients.
Regards, George
SCJP, SCJD, SCWCD, SCBCD
Now, my problem is that I can't think of a way to handle multiple concurrent requests (really) without using an in-memory data cache.
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Even with a cache, you are still going to have to write the data back to the file at some point. Unless you create a seperate thread to handle writes, and just queue them, you are still going to have to drop back to a synchronized block at some point.
... (record number validation, physical read, breaking into fields, converting to Strings ....). Now think about how many of those steps can be done concurrently.
Jacques<br />*******<br />MCP, SCJP, SCJD, SCWCD
It's early in the morning, and I think I'm a bit slow , but how do I go about doing everything, besides the raf access, concurrently from within my singleton Data object?
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Just being a singleton does not stop multiple threads operating on it
Jacques<br />*******<br />MCP, SCJP, SCJD, SCWCD
Why don't you sync on the cache whilst updating ?
Or if not using a cache use filechannels instead of raf.
Jacques<br />*******<br />MCP, SCJP, SCJD, SCWCD
Originally posted by Andrew Monkhouse:
Just being a singleton does not stop multiple threads operating on it
Originally posted by Jacques Bosch:
I know that. But then the calls can interfere with each other.
I.e. In the method you used:
2 threads call this at virtually the same time. So, since it isn't synchronized, what prevents the two calls from messing with one another's variable values?
I deliberately wrote the doSomething() method to be thread safe. It does not use any instance variables, so it is quite safe for two threads to run it simultaneously.
Here's a minor modification to that method to put in a few method variables which should not be affected by multiple threads:
When I ran this, I got the following output:
I can see that thread 0 started first, but thread 1 finished first. So if there was going to be any corruption then it would be visible. But that is not the case - I can see that the method variable is still set to it's original value, and the List contains only the single item that I expect.
However, if I was doing anything that was not thread safe (modifying an instance variable or a static variable) then I would have to take steps to make the method thread safe.
For a method like your find() method, you may find that you do not need to use any instance variables or static variables. You may be able to build the entire method using method variables. In which case you should be able to run multiple threads on that method simultaneously.
Regards, Andrew
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Jacques<br />*******<br />MCP, SCJP, SCJD, SCWCD
Well, Andrew. Would you believe it: You have help me greatly by clearing that up for me.
So, back to my cacheless design:
If I synch on the raf access only, and do everything else in unsynched, but synch-safe code, more concurrent processing will be achieved, only waiting when actual reads/writes are done on the raf.
Right?
Jacques<br />*******<br />MCP, SCJP, SCJD, SCWCD
Hi Phil. (Nice weekend?)
...or even better (and much simpler), use a FileChannel got from your RAF : FileChannel is thread-safe and allows concurrent access through the methods which take an explicit position.
Jacques<br />*******<br />MCP, SCJP, SCJD, SCWCD
So, using a FileChannel, I don't have to explicitly synchronized on my raf every time I do a read or write like I'm doing now? And it allows concurrent reads?
File channels are safe for use by multiple concurrent threads. (...) Only one operation that involves the channel's position or can change its file's size may be in progress at any given time; attempts to initiate a second such operation while the first is still in progress will block until the first operation completes. Other operations, in particular those that take an explicit position, may proceed concurrently; whether they in fact do so is dependent upon the underlying implementation and is therefore unspecified.
Effective concurrency will be performed only when methods take an explicit position (a "long position" as parameter) Even in that case, it's not garanteed ("dependent upon the underlying implementation"). But this is not an issue : after all we don't *need* the garantee.
Jacques<br />*******<br />MCP, SCJP, SCJD, SCWCD
But how do I specify how many bytes to be read. Is that determined by the size of the ByteBuffer?
Jacques<br />*******<br />MCP, SCJP, SCJD, SCWCD
Don't get me started about those stupid light bulbs. |