Mike Ngo

Ranch Hand
+ Follow
since Oct 16, 2006
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 Mike Ngo

I waited 6 weeks. They had the grade in about 4 weeks but it was not updated in the history. I sent an email asking about the grade when I saw people here getting their result after 4 weeks.
17 years ago
17 years ago
You do a lot more when you develop desktop application. MVC framework, application navigation, screen layout, persistent, threading... These are provided for you when you develop j2ee applications.
Took me 3 weeks to code and unit test.

However, i can't see the occasion where i need to throw a RecordNotFoundException



what if the recoNo does not exist in the database file?

That is right. Can different threads have different file pointers? I think the answer is YES. Back to the locking above, if different threads work on different records and each has it's own file pointer, then there is nothing to worry about since they are writing data to different track/cylinder/segment. Remember that JVM will take care all the stuff about writing your data to the disc(CS303/CS304 "File Structure" right?).

If threads are working on the same record, then there is a risk that the record is over written by the threads. That is why the lock/unlock is required. When a record is locked, there will be only one thread writing data to that record. So this is the reason for the locking(not for the logic). Locking is not to make sure the file pointer working properly. Again file pointer is controlled by the JVM and your operating system, Windows XXX probably. By the other word, how your data/record is written to disc is not controlled by your code. It is by JVM. You don't worry about it.

Now, you see I did complete my school... not dropped out right;-)



Sounds like you rely on the operating system to handle file locking, i.e. each thread open the file, update one record, then close the file?

My testing shows OK. You may synchronize the context in your update(). It won't hurt. Good luck.



Did you try multi threads updating different records? The threads won't be blocked and will try to update different records at the same time.

still a bad choice.
I'd subtract points for it were I an assessor, and might cause it to be an automatic failure depending on the exact wording of the requirements document.



Luckily you were not!
put win32com.dll in the windows dll dir (I think it is Windows\system32)
17 years ago

Look at your web browser. Is it necessary to guess _any_ address when you click Help->Help Contents (in FF)?



Well, you are assuming that the help doc is installed WITH the application.
My (html) user guide is external to the application and can be hosted by a web server. I have a help browser that the user can optionally view the help from within the app.

that's the worst possible option.
How would the user know where to find the userguide except from the userguide?


Look at your web browser. How people find out about javaranch or other sites, dude? What if the help doc is hosted by a web server?
Add a text field at the top of the help window so that the user can enter the URL of the user guide.

which is downloaded and serves as the stub...




Are you saying that the class java.lang.reflect.Proxy is downloaded?



Are you saying that the class java.lang.String is downloaded?

Both classes are in rt.jar. Show me where is the class downloading.

However, you are indicating that you have not used the rmic compiler. This means that at runtime the server JVM must generate the stub files, which must then be dynamically downloaded by the client JVM(s).



This is not true. If the stub is not pre-generated, you get back a proxy instead of a stub.

Object o = this.registry.lookup("DataHandlerServer");
System.out.println("lookup result: " + o);

Do you think calling first find from client side and then loop read is a good approach, where our DB is sync?



No, it is not. For ex, if you have 20 matched records, you will make 21 network calls to get the results (1 call for the find() and 20 calls to retrieve the record data).

Return types of read and find methods are String[] and int[] respectively. If you see client side, its seems difficult. How client can know the number of matched records to loop read? Putting everything (all records) in single String[] and then sending it to client does not seem a good idea.



The client should ask the server to do the search and return the result in ONE network call.
Your method should be something like this:
ArrayList<RecordData> searchRecord(criteria)
where searchRecord() will call find() to get a long[] and loop thru the array and call get() and build and return the ArrayList<RecordData>

Is it a good idea to add more methods in DBMain interface? find method of DBMain returns only record numbers but we need records data to display on JTable at client side.
It can be done at client too after getting record numbers but I am not sure which approach is better. Please comment!!!



You don't need new methods. Use readRecord(recNo) and build the record data list at the server side and send them back to the client.