This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Multiple Database Files Support Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Multiple Database Files Support" Watch "Multiple Database Files Support" New topic
Author

Multiple Database Files Support

John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937
I have some doubts about my design regarding connecting to multiple database files on the server. The reason I decided to implement my assignment with support for multiple database files is because of the requiremnt that says that the command line argument can be "Data file name(s)". So my server holds a Collection that contains the references to already requested databases, and the factory returns these references (wrapped in the remote object) to a client.
However, this complicates the assignment quite a bit, and requires some awkward solutions. For example, for local access, the client will have to specify the database path and name, but for remote access, the client will specify server port, DNS, and database name (but no path). To avoid this, I could of course map the database names to their purpose (for example, db.db is FLIGHT_TABLE, db1.db is PASSENGER_TABLE), and let the user specify the table by name. But this will violate the other requirement that the user must be able to specify the database location.
After all these troubles, I am actually leaning towards NOT providing support for multiple databases. That is, in local mode, the user will just browse the database file, and in remote mode, the client will specify the server DNS and port only (no references to a specific database).
But that will make it hard to justify the server design choices, as adding the new databases in the future will require significant coding changes.
What are your thoughts on this, guys?
Eugene Kononov.
Eduard Jodas
Ranch Hand

Joined: May 14, 2002
Posts: 80
This is what I'm doing:
- I allow the server/client to work with multiple databases
- The server doesn't know which databases to work with. It just knows the directory where to look for them. This directory can't be specified by the user (as it is not in the possible command line parameters) but it is fixed and relative to the working directory.
- The server has two methods: 1. create database, which creates a database in the database directory; 2. open database, which opens or connects to an already opened database. This two methods match the Data constructors.
- The server ensures the database names (which are paths) fall inside the database directory
- When working in local mode, the client just provides a database path. This must be either absolute or relative to the working directory.
- When working in remote mode, the client must provide the database name (which is a path relative to the server's database directory) plus a DNS and port.
I don't mean that's what we are supposed to do. It's just what I'm doing to fulfill what I think are the assignment requirements.
Ed
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

- When working in remote mode, the client must provide the database name (which is a path relative to the server's database directory) plus a DNS and port.

I don't understand this, -- are you saying that
the user provides the database name, which is in the path relative to the server's database directory? Or the user specifies the directory relative to the server's database directory?
Eugene.
Robin Underwood
Ranch Hand

Joined: May 01, 2002
Posts: 117
I think that what you guys are proposing is optional. I think that Sun's instructions are just limiting what can be entered in the command line, and none of them are required.
Jason Boutwell
Ranch Hand

Joined: Apr 02, 2002
Posts: 40
After all these troubles, I am actually leaning towards NOT providing support for multiple databases. That is, in local mode, the user will just browse the database file, and in remote mode, the client will specify the server DNS and port only (no references to a specific database).

I think that the extra effort involved in adding multiple DB support doesn't buy you enough to justify it. Plus, the added complication could prove detrimental. You have to balance the extensiblity requirement with the junior developer requirement.

But that will make it hard to justify the server design choices, as adding the new databases in the future will require significant coding changes.

Not necessarily. The Data Access Object pattern is tailor-made to solve this problem. It uses Abstract Factory to handle multiple data sources. Once in place, additional databases and/or tables can be added by simply implementing one interface and inserting a few lines of handler code in the factory.
But again, I think that this is SCEA level stuff (and I'm looking forward to it). You could be docked for adding excess levels of difficulty on this assignment.
Your mileage may vary.
Eduard Jodas
Ranch Hand

Joined: May 14, 2002
Posts: 80

I don't understand this, -- are you saying that
the user provides the database name, which is in the path relative to the server's database directory? Or the user specifies the directory relative to the server's database directory?

The second.
Let's suppose:
- the server dns is fbnhost
- the server port is 8080
- the server database directory is "c:\database\data", so that all database files are inside this directory.
- the server has two databases: fbn/db1.db, fbd/db2.db, so their local absolute path would be c:\database\data\fbn/db1.db; c:\database\data\fbd/db2.db
My client's command line would be:
> java fbnclient fbn/db1.db fbnhost 8080
The server would add "c:\database\data\" to "fbn/db1.db" in order to find the database file.
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

My client's command line would be:
> java fbnclient fbn/db1.db fbnhost 8080

And what if the client wants to open another database? You will require that the client exists and restarts:
> java fbnclient fbn/db2.db2 fbnhost 8080
And why is the user required to know the directory on the server? And what do you do with lock managers, create one for every opened database? See, -- that's what I am talking about: too many complications, and I am afraid that Sun might mark down our (similar) implementations.
Eugene.
Eduard Jodas
Ranch Hand

Joined: May 14, 2002
Posts: 80

And what if the client wants to open another database? You will require that the client exists and restarts:
> java fbnclient fbn/db2.db2 fbnhost 8080

I was just giving an example. The client can choose whatever way it needs to specify a database and server connection. Having multiple database support server doesn't prevent an application client from having a beautiful dialog for database connection/disconnection.
The client has not multiple database support. Only the server does.

And why is the user required to know the directory on the server?

?? No, never. For the database server, a database file name is like a java class name. When you load a Java class you don't know its location, only its package and name. There is a classpath environment variable set somewhere by someone which contains the classes physical location. But you don't need to know this location when loading the class.
My database server knows the classpath (the base database directory) and the client just gives to the server the database package and name.
My server is dynamic, like Java. It doesn't know the databases to load at startup. It discovers them dynamically as the application clients request them.

And what do you do with lock managers, create one for every opened database?

Of course. I have a LockManager factory, which dispatches a LockManager per database file. Just a couple lines of code

See, -- that's what I am talking about: too many complications, and I am afraid that Sun might mark down our (similar) implementations.

What I am sure about is that Sun will not mark you down for doing more than the expected. They will only mark you down if you do less.
What I'm doing is not difficult. I first created a server with only one database support to identify the data required. Then I created a class containing this data and a Map with <database file, database data> pairs and, behold!, I had a multiple database support server.
Why having multiple database support?
- the classes provided by Sun support multiple databases. The Data class may open different databases with different schemas. Our criteriaFind method must work no matter the schema of the database opened. All this only makes sense if FBN plans to have more than one type of database, I mean different databases with different schemas.
- What are we, FBN developers, going to do? start a different database server for each database file? Make future application clients worry about two/three different servers? Don't you think it is better to have just one server handle multiple databases?
- My server is not perfect, it will need modifications for future applications. But I find multiple database support a basic feature: not needed right now but yes in the near future. My present FBN application client will not have to be changed because the server basic structure is not likely to change.
- It is NOT difficult to implement. I'm not creating a full database server with tables and rows, just a server with pointers to more than one file.
The decision of having a multiple database server is justified but what if at last it is not required? Nothing, I will have enjoyed it a bit more.
 
Consider Paul's rocket mass heater.
 
subject: Multiple Database Files Support
 
Similar Threads
NX: (HTL) FileChannel & Threads
gui client command line arguments
Don't understand mode flag
Passed Certification. A few thoughts.
client server