• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

SCJD Exam Book: Why is 'database' Static?

 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've been reading thru SCJD Exam (2nd Ed.) and was wondering why the variable 'database' in DvdDatabase is static (p. 135)? It is defined as:

private static DvdFileAccess database = null;

Each call to the DvdDatabase constructor resets the value of database to a new instance of DVDFileAccess, as in:

public DvdDatabase(String dbPath)
throws FileNotFoundException, IOException {
database = new DvdFileAccess(dbPath);
}

This would seem to preclude possible future flexibility of having two different databases in use. It also complicates understanding the code and debugging since this means that an existing DvdDatabase object could magically start calling a different underlying DVDFileAccess object during its execution whenever another call to the DvdDatbase constructor was performed. What am I missing here?

I do see that DvdDatabase uses a static
 
Ranch Hand
Posts: 443
3
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I tend to agree with you.

In his defence if you reading the text I can see what his design aims are, i.e. he's effectively forcing you to always use only one database while not restrict the interface so that its hard to change it in this way later i.e. he's avoiding the singleton pattern so you don't have to get the only instance of the one and only DVD database and he's done this at both a DBClient and DvdFileAccess level with his use of static and check there is only ever one db file (by path) . If he did use the standard singleton pattern and you wanted more than one dvd (flexibilty as you suggest) he'ed have to change the interfaces to the class and he's not gone the generic route has you have to deal with the issues of two files.

Again I see what your both getting at the actual code he's generated for me is at best odd (particularly the static) though not wrong as such but I do take on board his comment.

For me I would have gone for a pure singleton or a pure generic database rather than trying to do a hybrid, i.e. one that works as a singleton now but whose interfaces were easily adapted to generic use. I suspect I'll write a generic class and use it from a seperate a singleton instead.

If I hadn't read the book and just seen the code with no comments, and had no idea of the level of programmer who had implemented it I would have assumed a design mistake (though actually thats wrong).

It is personal preference though and hopefully the examiners are looking for more clear documentation of the design choice rather than only this design is right.
 
Michael Creech
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I guess what I'm not understanding is why the static is needed at the DvdDatabase layer given that DvdFileAccess only allows one named database open (only one RandomAccessFile). If you didn't have 'database' as static, wouldn't all his goals still be met (one underlying database could be open and no singleton interface)?
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I was just thinking the same issue. Why the attribute database (DvdFileAccess) is static in this case? Isn't it that the creation of DvdDatabase that should be static in a single VM (i.e. a single server instance will only have a single DvdDatabase - hence static + once instantiation only). When I looked at the code of the server, it seems the DvdDatabase is indeed created multiple times for multiple client access, in which case multiple DvdFileAccess also created. Plus the RandomAccessFile attribute in DvdFileAccess is not static, so on new construction it always null, while the dbPath attribute is static but not used for checking in the code (I think it was originally using dbPath in the book, which make more sense in this case).

My head hurts..
 
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
Good question!
I am also reading Andrew's book.
Also ReservationManager instance is a statice member in the DvdDatabase,
Then the record Map is also declared as static.
But I used singleton for both LockManager and DBFileAccess (equivalent to the DvdFileAccess).

Ziji
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic