• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Data Class Query

 
Andy J
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I passed the programmer exam a couple of months ago and have now downloaded the developer assignment FBN. At the moment I'm still
finding out how the classes hang together and have a question.
Within the assignment the Data class provides basic database services. One of the constructors takes the the name of the database file and sets a number of instance variables including the current recordCount. This means that each time I create a new Data object the record count is only valid at the point of creation. For example :
String [] record1 = new String[] {. . . .};
Data connection1 = new Data(fileLocation);
String [] record2 = new String[] {. . . };
Data connection2 = new Data(fileLocation);

connection1.add(record1);
System.out.println("\nTotal Number of Records(Connection 1 after) = " + connection1.getRecordCount());

connection2.add(record2);//Falls over here within the invariant method . . .
System.out.println("\nTotal Number of Records (Connection 2 after) = " + connection2.getRecordCount());
If I run this test code the invariant method throws a RuntimeError. This is because when connection2 calls the add method its instance attribute recordCount, is now out of date due to the addition of a record to the file by connection1.
There are a number of solutions to this problem, most involve changing the implementation of the add method. Is this an acceptable approach? Is it okay to change the existing implementation of the Sun supplied Data methods ? Is this really a problem or am I completely mis-understanding the way Data works ?
 
Catherine McManus
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andy
I have only had a quick read of your post and one thing that strikes me is that you are creating two Data objects for the same filename. Data represents the database, ie the file. If you create two data objects, then you have two things accessing the file independently, and they are not communicating with eachother. If one Data object changes the file, the other one will not know about it,so it will be out of date, and you get the invariant error.
The solution is to only have one Data object. I certainly would not do anything as drastic as changing the add method.
Hope this helps
Catherine
 
Andy J
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Catherine,
I initially though that this was an option, but was put-off by fact that recordCount was not static which sort of implied
that a new Data object should be created for each new connection. As you suggested, I could make Data a singleton and have each client talking to some other Server object which inturn references the Data singleton.
The downside to this been that the single instance of Data with synchronized methods could become a bottleneck under any type of load.
I supposed as long as these type of assumptions are documented, and are at least recognised, I will not be penalised for the final implementation.
Again, thanks for you time Catherine.
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Andy J:
I initially though that this was an option, but was put-off by fact that recordCount was not static which sort of implied
that a new Data object should be created for each new connection.

It implies that you can create multiple Data objects, not that you can point them at the same file...
As you suggested, I could make Data a singleton and have each client talking to some other Server object which inturn references the Data singleton.

I don't think it makes sense for Data to be a singleton! It's quite legitimate for a database to have multiple tables.
The downside to this been that the single instance of Data with synchronized methods could become a bottleneck [...] I supposed as long as these type of assumptions are documented, and are at least recognised, I will not be penalised for the final implementation.

It would be a very strange world indeed if you would be penalised for properly synchronizing access to shared resources When done well, the synchronization will not become a bottleneck. Essentially, it's how enterprise-level DBMSs work too.
- Peter
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic