• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

DataManager class

 
Paul Bench
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

I'm just starting out on the Bodgitt & Scarper assignment and as a starting point I thought I'd have a go at reading the supplied data file. I added a couple of methods to the compulsory Data class to read things like the schema, for example. No problem so far.

However, I've noticed some posts talking about a DataManager class. I'm not sure what this would be (i.e. what functionality this would provide) - can anyone clarify?

Paul.
 
Yevgeniy Treyvus
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The DataManager class is not required. It is up to you how you want to implement the assignment. But some people found it useful to put any additional logic needed to track the data into a separate class. As I said it is not required. It is purely under your discretion - in other words, do so if you feel it makes your design better.

If you look at how your data file is designed, chances are you won't find any entries for storing things like record Id's, cookies, and perhpas "pointers" into your DB file to tell you where a record is located. That sort of information you have to track elsewhere. My guess is that's what most people use the DataManager class for. In addition you need to put any additional logic there - for instance, if a record is deleted you need to update the information stored in your DataManager class.

You can probably get away with doing all that in your Data class, but it may become overblown.
 
Paul Bench
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

Thanks for the reply. So would such a class extend the Data class?

I also have some followup questions. My first draft only implements the read method in the Data class and I've simply declared and opened the file stream in the read method. When I implement the other methods should I declare the file stream as an instance variable and open it only once? Some threads seem to suggest opening it statically. What are the advantages of one way over the other? Presumably only one client can write at a time but how about reading?

As you can see I'm pretty confused so any pointers would be welcome.

Paul.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Paul,

The DataManager (and LockManager) classes - if you have them - would be called by the Data class. This makes the Data class itself a Facade.

A potential problem with opening a new stream for each connected client is that this could consume a large number of file descriptors. Some operating systems only have a limited number of file descriptors and/or limit the number of file descriptors available to a single process. You can get around this by developing a pool of file descriptors, or you can go an easier way - just have a single static file descriptor .

Regards, Andrew
[ March 27, 2005: Message edited by: Andrew Monkhouse ]
 
Ian Hamilton
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,

So to avoid the OS running out of descriptors we can attach several streams to a single static file descriptor..

However can you explain why we need a file descriptor?? If a new client connects we read the whole file, and if we know the position where we would like to write we can use seek() to set the filePointer (after which the filePointer is always reset to the beginning of the file).

Why do we need to remember the last read/write position?
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The File descriptor is represented in Java by a File object.
If you create a distinct File object for each client, you can run out of them like Andrew said.
 
Ian Hamilton
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for replying Jereon.

If we have a single static file descriptor/file object doesn't this prevent concurrent read/write access? i.e. we will only be able to do one seek() at a time to ensure file pointer is positioned correctly? so

Client A would like to update record 2
Client B would like to update record 5

but Client B must wait until Client A releases the lock and resets the file pointer to start of the file?
[ May 25, 2006: Message edited by: Ian Hamilton ]
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
indeed it normally will (some operating systems might have different logic).
But that's why you synchronise your file access methods.
And remember that those methods take only milliseconds to complete, unless you have a massive number of clients doing simultaneous requests for large amounts of data you should have no problems.

Using multiple File objects for a physical file is far more tricky (and might lead to its own problems, operating systems may well not allow it).
If File object #1 writes to the file while #2 tries to read the same record, can you tell with any degree of certainty what #2 will get for example?
Now imagine 2 File objects writing the same record at the same time, what will actually appear in the physical file?
 
Ian Hamilton
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jereon, thanks again for your reply.

http://www.coderanch.com/t/188260/java-developer-SCJD/certification/Suggestions-approaching-SJCD

Basically you need to keep track of records locked by individual clients to make sure there can be no 2 clients trying to modify the same record during any particular time period.


I notice in the above thread you discuss keeping track of which records are being modified. I assume this isn't necessary with a single static file descriptor?
[ May 26, 2006: Message edited by: Ian Hamilton ]
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
it is.
The actual file operation is only part of the logic cycle involved.
When a client locks a record he indicates an intent to modify it, preventing others from indicating such an intent as well.
 
Ian Hamilton
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ok I get it. So while a static file descriptor prevents concurrent access to the actual file, by keeping track of which records are being modified I can allow concurrent record modifications to take place - but the file will only be updated one modification at a time.

[ May 26, 2006: Message edited by: Ian Hamilton ]
[ May 26, 2006: Message edited by: Ian Hamilton ]
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
not really. You don't even want concurrent modifications.

What if you have 2 clients who are both trying to book a record at the same time? The first booking would be destroyed by the second.
 
Ian Hamilton
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When I say concurrent modifications I do not mean to the same record, this is why we cache which records are being modified to prevent such an occurrence - if a user attempts to modify a record that is locked we can let them know it is unavailable.

So if we can prevent a user editing a record that is locked, where is the harm in allowing concurrent modifications?
[ May 26, 2006: Message edited by: Ian Hamilton ]
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ah, thought you were thinking there's no use for locking if you have synchronisation...

Safety first I'd say. But that's not all. What if someone tries to read a record while you're writing it?
[ May 26, 2006: Message edited by: Jeroen T Wenting ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic