Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Confused: Db File

 
pascal auderset
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic