File channels are safe for use by multiple concurrent threads. The close method may be invoked at any time, as specified by the Channel interface. 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.
Originally posted by Jim Yingst:
[Max]: I suggest establishing a FileChannel as you need to, not in case you need to.
Really? That's surprising to me. I assume you mean, create a new RandomAccessFile, FileInputStream, or FileOutputStream (as needed), get the FileChannel, do your business, and then close everything? For each update, at least? (And probably each read as well, unless you're saving everything in memory after startup.)
The thing is, I'm not entirely sure what's supposed to happen if you have more than one RAF or file stream open on the same file at once. Part of me expects the operating system to throw some sort of error - I swear I've had troubles with this sort of thing in the distant past, though I can't seem to replicate them now.
Originally posted by james render:
oh no, I've lost the plot here... can we go back a bit..
currently I've not synchronized anything for File I/O.
once a thread has obtained a lock on a particular record (or not if its reading), it opens up a FileChannel and does its business.
I thought that because all the FileChannel business is done at a method level there was no danger of threads stepping on each others toes (because of the record locking mechanism).
Jim was arguing in favour of a single FileChannel instance so long as you used it atomically but Max said its okay to use them JIT.
BUT are you saying Max that if you use them JIT you'll need to make sure that no two threads are hitting the file at the same time... in which case use some sort of static instance monitor - in which case its not that different from having a static FileChannel, you have the hassle of ensuring the synchronization but without the worries of closing the file..
I had created a mechanism for ensuring that two creates didn't occur at the same time..
sorry brain is fryed @ the end of day here...
As for the latter, the only thing you have to do is lock down the entire db when a create or delete is taking place, say by using a lock(-1). Otherwise, all's well.
I still prefer the single FileChannel
Originally posted by Max Habibi:
Sounds like a good analysis and a reasonable design. By using only a single Data object, you're cutting down on the complexity, and by making the FileChannel a private member of Data, you're keeping it serverside. Sounds like a candidate for a perfect score.
Originally posted by Jim Yingst:
So, each adapeter has its own Data instance, which has its own FileChannel, which refers to the same single data file, right? Sounds reasonable. I still have a certain paranoid distrust of multiple channels attached to the same file, but you're [ahem] probably safe.
It might be worthwhile to create some tests for this. One thread could keep updating a record so all fields are filled with XXXXXXXX, while another thread tries to update the same record with YYYYYYYY. Meanwhile another thread keeps reading the record to see what the fields look like. They might observe all X or all Y, but if they ever see X and Y in the same record, that's an error. A similar test could look at simultaneous creates. One thread creates 1000 new X records, another creates 1000 new Y records. Afterwards check that there are 2000 new records, 1000 of each type. (Whatever order they occur in.) Somethign similar can probably be done with delete too, but I'll leave that to you.
Note - if my second paragraph above makes no sense, it may be that I'm misinterpreting the assignment, so let me run this part by you. I see in the spec, "the program must allow the user to specify the location of the database, and it must also accept an indication that a local database is to be used..." OK, the latter part is handled by command line arguments defined elsewhere. But does "location of the database" mean "where's the server?" Or does it mean "once we've found the server (or localhost, which ought to be pretty easy if that's what requested) - what's the path to the DB file?" I'm assuming it's the latter, and this this means different clients may connect to different DB files through the same server. But I may be way off here; please let me know.