wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Confused: Db File Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Confused: Db File" Watch "Confused: Db File" New topic
Author

Confused: Db File

pascal auderset
Greenhorn

Joined: Aug 21, 2002
Posts: 15
Hi
I'm a little confused about requirements for db file(s).
Is it required that the client can connect to different db-files (over network)?
As I understand the business case, the company has one db file in which all theirs flights and destinations are stored. Is this a misunderstanding?
So the server could be startet like this:
java -jar server.jar <port> <dbfile>
And the client could connect:
java -jar client.jar <machinename> <port>
The client could get a connection to the dataserver without the need for a dbfile.

If a client likes to access the dbfile locally then:
java -jar client.jar <dbfile>
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

Is it required that the client can connect to different db-files (over network)?

See this discussion regarding serving multiple database files. The short answer is that it is implicitely required.
Eugene.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

I have never seen this requirement. I doubt that my submission would allow a different db.db file to be used. In my current state of the code. Changing it to allow different ones would be easy to change.
I am sure you will not be marked down for it.
Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Hmmm, looks like a bit of a communication breakdown.
The client will only have to talk to a single db.db file at a time. You have this file fully specified on the command line, so it can reside anywhere, or fix the filename or even the location relative to the jar; I doubt it makes much of a difference.
The database server only has to serve up access to a single database file. There is no requirement for anything more.
I think Mark is talking about these two.
There is some difference of opinion about the networked database classes that you write (and use to realise the database server).
I think Eugene is talking about the latter aspect.
My own observations on this last point are that (a) the supplied Data class is completely generic, allowing you any table layout and any number of instances (b) you are coding only part of the full FBN system and (c) my instructions explicitly asked me to code for reuse (is that still there?). From (a)-(c), my conclusion is that it ought to be possible, in theory, to have any number of instances of your networked data class. This doesn't make things more complex, to the contrary: you will in most implementations have to go out of your way to make it work differently (like introducing a Singleton somewhere). That seems silly. With the ability to have multiple instances, the code becomes an awful lot more reusable.
On these grounds, I have been arguing against using Singletons on quite a few occasions.
Does that summarise things fairly or am I missing a point?
- Peter
pascal auderset
Greenhorn

Joined: Aug 21, 2002
Posts: 15
Hi
Hmmm, looks like a bit of a communication breakdown.

I think so ...
... I think Mark is talking about these two.

That's what I understood when I read the instructions the first time. Then I read some posts and got confused.
My own observations on this last point are that (a) the supplied Data class is completely generic, allowing you any table layout and any number of instances (b) you are coding only part of the full FBN system and (c) my instructions explicitly asked me to code for reuse (is that still there?). From (a)-(c), my conclusion is that it ought to be possible, in theory, to have any number of instances of your networked data class. This doesn't make things more complex, to the contrary: you will in most implementations have to go out of your way to make it work differently (like introducing a Singleton somewhere). That seems silly. With the ability to have multiple instances, the code becomes an awful lot more reusable.

a) The class is still generic. I have a question to the "any number of instances". As I understand, one instance of a data class correspond to exactly one datafile (db.db). Are you designing the Data class in the way that more instances of the Data class represent one datafile? I don't think that this works with the RandomAccessFile in the Data class.
b) Yes.
c) Yes.
Until now I have a design like this:

I'm not yet sure about the implementation of the lock. Until now I use a LockManager Object. The problem is the the methods need the clientId.
I could implement the lock directly in the FBNServiceImpl. Then I dont use the methods in the Data class.
The other solution is to extend the lock/unlock method on the Data class with the clientId. But this is against the specification. So what should I prefer?
Thanks for help
Pascal
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by pascal auderset:
I have a question to the "any number of instances". As I understand, one instance of a data class correspond to exactly one datafile (db.db). Are you designing the Data class in the way that more instances of the Data class represent one datafile?
G-d, no. You can actually make this work, but that's a snake pit you don't want to get anywhere near to. What I meant was using multiple Data instances to respresent multiple files (==tables).
[...] The problem is the the [lock/unlock] methods need the clientId.
I could implement the lock directly in the FBNServiceImpl. Then I dont use the methods in the Data class.
The other solution is to extend the lock/unlock method on the Data class with the clientId. But this is against the specification. So what should I prefer?
There are multiple schools of thought on this one.
One school says that even in local mode you can have multiple threads contend with each other for locks, so Data needs some kind of locking implementation.
The other school says that that in local mode there is generally no need for locking, so the no-op implementations in Data are just fine as-is (just like it's OK for Connection to have a close() implementation that is essentially a no-op, except for some paranoia cleanup). In the rare cases that you want a local-mode database with threads contending for locks, well, simply use the ConnectionFactory and Connection classes. They work just as well locally as remotely.
Does this help?
- Peter
 
wood burning stoves
 
subject: Confused: Db File