Ben Nichols

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

Recent posts by Ben Nichols

Yes... They are capable of virtual concurrency.
But you shouldn't allow concurrent access for writes.
You should allow two threads to concurrently read, and make the
file interface class synchronize and block for the file pointer.
And you should block concurrent writes, since you cannot predict the final state the data will be in. I probably didn't answer your question.
This is not a problem you should be experiencing.
If it is a problem that you are experiencing with your Fly By Night assignment, then your assignment differs from mine, or you have gone way too deep.
Think of the assignment as an excercise in following directions vs. good program design. (Developer vs. Architect)
They purposefully did that to antagonize you.
But there is also a hint in the directions...
"lock, read, modify, write, unlock...."
The network client must implement all of the public functions of the data class.
But the GUI client has a separate set of requirements that do not include add, close, find, and so on.

My guess is that it is our job to follow the strict requirements, and that development above and beyond that only has the capacity to reduce our score. At least, I have had a number of CS programming courses where that was the case. It was due to the fact that the developer's largest task is to follow directions exactly, because developers typically develop only a piece of a fully functioning app, and they are typically coding on someone else's clock. If you add unrequested functionality, and someone else is developing that piece, or they haven't budgeted for that portion of the software yet, you are wasting someone elses money and your own time. I especially believe this because Sun has an additional certification for program Architects.
Another method that could be used to shut clients down, but not during a request is:
boolean isUnexported = [UnicastRemoteObject].unexportObject(ref, false);
This only unexports the object if there are no pending or in-progress calls.

Try this... (First of all I know that this is not a pretty way of doing this... but, it should work...)
1.create a local RMI client instance.
dummyClient = new RMIClientWrapper();
When the server attempts to close:
1. Unbind the RMI ServerName( this prevents new clients)
2. close your dummy client instance(set to null, whatever)
When unreferenced get called
1. exit (and other cleanup)
The rmi garbage collector uses default 10 minute leases so if you have Leased active stubs out to downed network connections, it should clean them up by then.
On the flipside, I don't know whether RMI clients need the ServerName bound to renew their active leases if they are still working. I would test this, but it would seem odd. I believe the Server Name only has to be bound for a client to receive the initial copy of the stub.
if implemented would allow your RMI Server to be notified when there are no more active clients...
but tell me... why would you want to do this?
I am curious as to how that would affect the assignment.
I wanted to add one more quote that I missed earlier from RHE, just so people are aware.
"Once the choice of network technique has been made, however, we can give a more thought to how threading plays a role in the whole scheme. This is admittedly a lot trickier in to contend with in an RMI scheme, and multithreading questions should be pursued early in an RMI scheme rather than later."(RHE, 499)
[This message has been edited by Ben Nichols (edited May 24, 2000).]
I looked into the java.rmi.server.Unreferenced interface.
I have been thinking of an application for it in the assignment,
and I don't quite get it. I don't want to be a pain, but could
you elaborate.
Thank you Peter
You can't guess how much that helps.
I guess I completely agree.
According to the Instructions:
<quote>"...must create a data server that will accept multiple concurrent network connections. ...because multiple concurrent network connections may exist you must make your server class threadsafe. may implement your threaded server in more than one class."</quote>
My confusion has lain specifically with the RHE book, which seems to strongly insist that there is much more multithreading going on than just the rmi...
<quote>"If multithreading is added as an afterthought [to rmi], the application could well be at risk."(RHE, 488)</quote>
following the rmi section:
<quote>"Up to this point...we've discussed threading...suggesting a few possible ways to deploy them, but without creating a robust, working model of any one type."(RHE, 490)</quote>
<quote>"One complex aspect of writing a multithreaded application server is choosing a way to define how client requests will run.(RHE, 490)</quote>
Additionally I leafed through one other SCJD book and it said something like, "when you implement your multithreaded server it will either need to extend Thread or implement Runnable."
These statements have collectively convinced me of requirements beyond the ones issued with the programming assignment, which is really what I am trying to nail down in this topic.
...may or may not execute in a separate thread.
My application can handle it if it does execute in a separate thread.
The RMI runtime makes no guarantees with respect to mapping remote object invocations to threads.
Does this mean that I must add additional code to guarantee the multithreaded execution of methods in my server class.

[This message has been edited by Ben Nichols (edited May 19, 2000).]
As I understand it, rmi creates new instances of the server object in a separate thread for each client connection.
It seems, at least according to the RHE book, that there is some strong level of expectation that multi-threading above and beyond that be implemented. "
I do not understand how any additional server side multi-threading could be implemented in a way that provides additional or even usable functionality to the project. I do not synchronize anywhere in the rmi server. The only time the letters "synchronize" appear in my project is in reference to a collection used exclusively by the lock and unlock functions in the data class extension. If any rmi server side methods are synchronized it opens the potential for a server side deadlock while the lock function blocks.
I have run tests to verify that rmi is using multiple threads and operating correctly as follows:
Using one instance of rmi registered server:
1. locked a record from a dummy client instance
2. requested a record lock for the same record from another client instance
3. Waited 120 seconds
while the second instance is still blocking:
3. locked a different record and then unlocked it from a third client instance
4. unlocked the the first record from a fourth client instance

5. The second instance then obtained the lock and returned.
6. Then I unlocked the newly obtained lock with the second instance

I sincerely do not understand the discrepancies between how my program implements multi-threading, and what most of the literature seems to suggest is required for the assignment.
Do you think most of the manual multi-threading implementation is referring to a sockets deployment, or is there something obvious that I am completely missing?
[This message has been edited by Ben Nichols (edited May 18, 2000).]
[This message has been edited by Ben Nichols (edited May 18, 2000).]
[This message has been edited by Ben Nichols (edited May 18, 2000).]
I would agree, except the client class is supposed to implement all of the public functions of the data class. This suggests that data processing (reads/writes) should happen above the client level.
Additionally, the server should be totally dataset independant, meaning that the server shouldn't be allowed to validate data, or even care what data is being updated, or know what the database looks like.
I think the project goal is to test us on a number of areas rather than to make a usable production level product. The scenario is to help us conceptualize certain elements of usage.