Meaningless Drivel is fun!*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: Bodgitt and Scarper File Access/Locking Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX: Bodgitt and Scarper File Access/Locking" Watch "NX: Bodgitt and Scarper File Access/Locking" New topic
Author

NX: Bodgitt and Scarper File Access/Locking

Tony Collins
Ranch Hand

Joined: Jul 03, 2003
Posts: 435
Just wonder if anyone could clear up some points I'm a bit confused about.
My Bodgitt and Scarper spec says:
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. You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.

How can the assumption be made that at any moment at most one program is accessing the database file ?
Seems odd to me considering one file contains all records ?
Additionally what is the advantage of having multiple instances of the DatabaseAccess Class ?
And if you did have multiple instances of the DatabaseAcess class, would the GUI have to remotely create an instance of the Database Access Class on the server ?
And would that violate the requirement below:-
You must provide all classes pre-installed so that no dynamic class downloading occurs.
Cheers
Tony
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
How can the assumption be made that at any moment at most one program is accessing the database file ?
Seems odd to me considering one file contains all records ?

I'm not sure I understand your objection. But what they mean is that only one program may directly access the database file. Where "program" == the whole JVM, in our case. Which may or may not have more than one class accessing the file; that's up to you. But you can assume that there are no other programs outside the JVM which will interfere with your reading and writing to the file.
If you're thinking "how do other users access records if only one program is accessing the file?" - the one program can be a server. Other users don't access the file directly; they just make a request to the server.
Additionally what is the advantage of having multiple instances of the DatabaseAccess Class ?
Well, it's one way of handling multiple clients. I don't see any realy advantages though, so I'll skip this part.
And if you did have multiple instances of the DatabaseAcess class, would the GUI have to remotely create an instance of the Database Access Class on the server ?
Umm, probably. The GUI couldn't directly create an instance on the server - but it could make a request to the server, and the server could have some code that creates a new instance and passes a remote reference to the GUI.
And would that violate the requirement below:-
You must provide all classes pre-installed so that no dynamic class downloading occurs.

No. We were talking about dunamic instantiation of a class, which is something programs do all the time. Dynamic class downloading is something else - it means that at compile time, you don't even know for sure what class definition will be used for a certain class, and the program needs the ability to go and find a new Jar file or class file (not one already on the classpath), read that file from wherever it is, and use it. Your JVM is actually loading classes for you all the time - but it normally does it from pre-installed libraries, things that are on the classpath. That's all you need here.


"I'm not back." - Bill Harding, Twister
Tony Collins
Ranch Hand

Joined: Jul 03, 2003
Posts: 435
Cheers, I got confused with program and client ?
Though what still confuses me is that the Data class is specified to lock on a record, so two threads could try to update the database file( different records) at the same time. Would this imply that the database would need some locking mechanism as well? And if so does this make record locking redundant ?
Thankyou
Tony
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Though what still confuses me is that the Data class is specified to lock on a record, so two threads could try to update the database file( different records) at the same time. Would this imply that the database would need some locking mechanism as well? And if so does this make record locking redundant ?
The database is what enforces record locking among all threads which try to access records, yes. I'm not sure what's redundant - what other locking is there? Perhaps you're thinking the DB progam can/should acquire a file lock (see FileChannel and FileLock in java.nio) to make sure other programs really aren't accessing the file - that's an option. But we've been told we can just assume there will be no other programs, so we don't really need to enforce this. If you do have a FileLock though, it's not redundant with record locking. They work at different level. The FileLock assures (or tries to assure, depending on the OS) that no other programs outside the JVM have access to the DB file - and this applies to the whole file. The record locking controls which clients have access to which records - all within the JVM. Both are potentially useful, though only record locking is required for the assignment.
Tony Collins
Ranch Hand

Joined: Jul 03, 2003
Posts: 435
Yes I thought the file would have to be locked as well. As two threads could try to open the file at the same time( to access different records) and I assumed that this contention would produce an exception. Is that not the case ?
Thanks alot for your help.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
As two threads could try to open the file at the same time( to access different records) and I assumed that this contention would produce an exception. Is that not the case ?
Apparently two different RandomAccessFile or FileChannel instances can access the same file at the same time without throwing an exception. I was a bit surprised by this myself. I can't find documentation that guarantees how (or if) this works though, so I don't really trust this behavior and prefer to avoid it. Especially when the different RAF instances are held by different threads - too many issues here I'm not sure I understand. Instead I (and, apparently, many others here) prefer to create a single instance of a class which can read/write to the file, and force all the client threads to access the file through the same shared instance, with explicit synchronization of critical blocks of code to protect muatable data from concurrent access.
Note - this instance may or may not be implemented as a true singleton; that's a more involved dicussion which depends on whether you want to support the possibility later for having several differernt DB files accessed simlutaenously. E.g. each one could represent a different table. But that's not importantt right now - you can think of the file-access class as being like a singleton, at least for the given assignment where there's only one file. For more discussion of this, search on "singleton" (and possibly "multiton") in this forum; most discussion you find will be about the data file access class.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: NX: Bodgitt and Scarper File Access/Locking
 
Similar Threads
Some questions on "Bodgitt and Scarper"
OCMJD - Bodgitt and Scarper Questions!
Bodgitt and Scarper : locking and unlocking
Bodgitt: Locking requirements
Bodgitt and Scarper : Data class