Jonathan Wolter

Greenhorn
+ Follow
since Nov 26, 2007
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jonathan Wolter

You could have the file location in a properties file. You can read and set properties like this:

(I'm using a junit 4 test to illustrate)

15 years ago
Here you go, a junit 4 test that may help someone. But I encourage you to try this yourself, as that's the key to learning.

15 years ago
Also, because the nature of static initialization blocks running when the class is loaded, you can *never* prevent them from running.

This is why it's often something you want to avoid in your own code, especially for expensive work that could happen elsewhere. It makes testing harder.
15 years ago
In many exam problems, we may assume only one "Server application" -- and if you choose, one thread - is accessing the database file. Do you have an implementation that suggests this thread safety issue is a problem? I must be missing something...

Jonathan
The interface DB has a read method:


I am not currently returning the recNo in this String[], because the database file itself does not have a notion of record numbers. (They get calculated on the fly by the database implementation).

Would anyone disagree with me on this? Do you think I need to return the recNo in that String array?


jaw
I am using logging, and I will include it in my final submission. I even wrote my own logging formatter (OneLineLogFormatter) to make the log file more readable.

Benefits I see outweigh the costs.

Logging clarifies the Concurrency code, and makes for better understood code, imho.

jaw
Thanks for your post.

For me Data.java must implement the sun provide DB.java interface. I wanted to use polymorphism for my Local and Remote objects (both would implement DB). But because Data.java threw method signatures that were incompatible with the requirements for RMI, I couldn't.

Fast forward to your suggestion: Add a business layer in to separate my application from the DAO*. Then, look at polymorphism in that business layer so that my remote and local objects can implement the same interface. That's my next step.

Thanks,

Jonathan
* http://en.wikipedia.org/wiki/Data_Access_Object
** http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
Thanks for the post.

So if I were to add another object in for the business layer... whew, I'd then have 3 objects with almost the same responsibility: 1) DB.java (sun's interface), 2) this new business layer object, 3) The remote client that uses 2 and then 1.

Right now in my client code, I've abstracted out into 2 types of DB: local and remote. These are contained in a DBFacade object, which then transparently (to its clients) handles whichever Data access method is used.

This seems really ugly... can some of the duplication be cleaned up?

Alex,

I'm not sure to take your reply as a suggestion or a question. Thanks for posting, though. I have slightly different instructions.

Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:

package suncertify.db;
public interface DB {...



This leaves me at the same spot I was before. Is there an approach when using RMI to reconcile two seemingly incompatible interfaces? One must throw RemoteException (right?), but the one given from Sun doesn't.

Jonathan
[ December 15, 2007: Message edited by: Jonathan Wolter ]
I have the Bodgitt and Scarper project, where there is a DB database interface.

I am using RMI, so I would like to have my RMI interface extend from the DB interface.

Problem:
I think RMI requires every method to throw RemoteException.

Yet, the DB interface given to me does not throw any RemoteExceptions (or any supertype such as IOException).


My Approach:
I duplicated the DB method signatures in another interface, DBRemote (except changing the throws to throw RemoteExceptions). This feels like a hack. Also, I now cannot interchange the remote or local implementation, since there is no polymorphism between the two. No common interface!

What can I do? Is this the best you can get when using RMI with an interface that does not throw RemoteExceptions initially?

To recap: I changed in DB.java (from Sun)


To this in DBRemote.java
I think so (for my instructions). According to Andrew's book, the dynamic generation involves downloading the stubs. But (my instructions) said I can't do that. No downloading of classes.
I didn't get to calculating the formula yet, but you may also have to add one for the 'deletion' flag, depending if you keep that in your record length number.

As for the header, that would include all of the schema: magic number, number of fields, field names, data length per field, etc.