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.