Jason Boutwell

Ranch Hand
+ Follow
since Apr 02, 2002
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 Jason Boutwell

Yeah Mark, bugger off! You act like you own the place or something!

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.


There are some more coding convention guides on the net. Follow the newer vesion. The one on Sun s site is pretty old.


Whew. That's not a guide on Ambysoft, its a dissertation.
The age difference between the Sun and Ambysoft guides is a mere 9 months. I doubt that there were any major breakthroughs in coding standards in that time.
I wouldn't deviate too much from this:
Java Code Conventions
You say tom-AY-to. I say tom-AH-to.
Whatever gets the job done.
Yeah. Looks like I needed to use JDialog, as opposed to JFrame.
Thanks alot.
I must be missing something.
I have a separate JFrame for Docs, but when I try to launch it with pack() or setVisible(), my program hangs.
I have a MenuItem that I click, and the listener code launches the docs JFrame.
The Swing tutorial tells me nothing about launching a frame from witin a frame.
Any suggestions?
Thanks.


If you use Data, and your locking is implemented in that class, then the locking will happen in local mode. That's what we are trying to avoid.


But your locking should NOT be implemented in Data, IMHO. Locking should take place ONLY in RemoteDataImpl, which in my case delegates the functionality to a LockManager.


except that the methods of Data will have to be defined in two places, actually four places, if you count the inteface: data interface, Data, LocalDataImpl, RemoteDataImpl.


The methods are defined in one place, the Data interface.
They are implemented in two places, the local Data class and the RemoteDataImpl class.
I guess that my design differs because I have the Data class implementing the Database interface, rather than using a wrapper object for local calls.
Can I get some opinions as to the best way to go for presenting the documentation (User Guide and Javadocs) from the GUI?
I see that JEditorPane with HyperlinkListener is a popular choice in some older posts.
I see that some folks have used plain JFrames and JPanels.
Others chose not to have a help menu at all.
I don't want to get too elaborate with it.
What is the (best) (easiest) (full score) way?
Thanks in advance!
Why do you need a LocalDataImpl? Why not just use Data?
If you define an interface with all of Data's methods, and both Data and RemoteData implement it, then you don't need to use 'instanceof'. Let polymorphism handle it.
Each to his own when it comes to storing your objects.
For me, my facade business methods return generic Collection types. It makes it easier to change down the road for whatever reason.
For example, after I had developed my GUI, I realized that I would like the Origin and Destination values in my search form to be alphabetized. Since I had use generic Collection return types, I was able to simply change my Collection from HashSet to TreeSet, and boom, alphabetized choices.
Gotta love that polymorphism.


I like this design because it allows locking to be done without modifying the signature of either methods.


You don't have to change the sigs. The remote object has a lock(int) call, which delegates to the global lock manager's lock(this, int). 'this' serves as the client identity.
I don't see any reason to have multiple levels of locking. A single lock managment class can serve all locking needs, and can also be re-used by other classes.
In proper OO design, according to me, , a single class should serve a single purpose, and be as decoupled from its client classes as possible.
As always, your mileage may vary.


What abt the following statement in lock(int) of Data.java
lockManager.lock(myRecord, Thread.currentThread));
In Local mode we can delegate the action to Data.java.
However in Network Mode the Connection object will directly call Lock Manager as given below
lockManager.lock(myRecord, this);
In network mode the response will not be delegated to Data.java


Sure, you could do that, but why implement any locking in local mode? Sure, some folks have come up with multithreaded ways in which a local client may need locking, but IMHO, that is out of the scope of the assignment. I don't believe that the re-use requirement is meant to account for such rare possibilities.
The locking method you describe for Network mode is identical to mine. However, I have NO locking code in Data.java. None. I left the methods in there because Sun put them there, and they aren't hurting anything.
Your mileage may vary.
You don't HAVE to leave those methods in Data empty. That's just the method I chose to use. Many other people have implemented lock() and unlock() in Data and passed the exam.
Each person must make his own design decisions regarding the implementation of locking, and explain those decisions in the design document.
I implemented lock() and unlock() in the remote Connection object, which implements the Data interface. So I am extending Data that way.
You should choose a method that makes your comfortable and that you are confident in.
Your mileage may vary.
I just went through this same issue.
I decided not to manage locks at the local level.
I have one global LockManager, created by the ConnectionFactory, that manages remote locks.
Each remote Connection has a reference to the LockManager, and passes lock calls to it.
My lock methods in Data are empty and never called. The LockManager has no knowledge of the Data class.
It works quite well.