Adrian Muscalu

Hi Mark,

Thanks for taking the time to answer.
It is a relief to know that I haven't misused RMI and the program behaves as expected.

Cheers,
Adrian

yes, I am sure.
Thanks for replying.

Hi everyone,

I was testing my application and I've discovered that after calling <b>unbind</b> and checking with <b>list</b> that the RMI registry doesn't contain the entry for my remote object, the clients can still invoke methods on the remote object at their leisure. No exceptions are thrown!!!

However, new clients get an exception (which is the right behaviour) upon trying to get a remote object.
Moreover, if I close the Server application completely than I do get the expected behaviour, the clients (new or old) will get an exception.

Now, I could close the server all the time without fancying around with <b>unbind</b> but I am afraid that I am only hiding a bigger problem; maybe my RMI approach is not the right one.

My remote object has an instance variable which is the Data class. All clients are expected to get stubs that point to the same instance of the remote object.

I am thinking that the Data class was passed somehow by copy and not by reference to the client.

Testing is done in the same JVM, on the same machine.

Any ideas on why this might happen?

Thank you all in advance,
Adrian

Hi,
I apologize for the confusion. What I meant was to provide a second JTable that is editable and is used only to capture users's search criteria. The search goes against the database as usual and the results get displayed into the other JTable.

Thanks for answering,
Adrian

Hi,

I don't have much experience with Swing but I was thinking that I could use an editable JTable to get the search criteria from user. It does look nice on top of the results JTable but I wanted to see what you ranchers think...

Thank you,
Adrian

Hi guys,
I have this idea and I'd like to know if anybody thought about it so far. I know how to implement it; I just want to find out if this is a good aproach from the exam point of view.
I want to have a Contractor class that will keep as member variables all the data for a particular record in the database (name, etc). I'd like to have this done dynamically, depending on the current database schema. That means, whenever I instantiate this object I will have to pass a reference of the database schema. The pair (fied_name, value) will be stored internally in each Record.
This will provide a great flexibility of the database schema change. Should another field is inserted into the database, the Record will know about it, the GUI interface will know (and will display it). Minimum impact on refactoring the code, affecting the users.
Is it worth the effort?
Thanx,
Adrian

Hi Bill,
I would leave the methods in. Part of my requirement states that the "interface should be designed with the expectation of future functionality enhancements [...]". I'd go as far as keeping the buttons on the interface and throwing a checked exception to specify that the feature is not implemented yet. This way, when the feature becomes available there is no need to re-compile the client code. It just gets activated.
It's a crazy idea, I'm not even sure I'd implement it but we are discussing possibilities...
Adrian

Vlad,
I haven't given much thought of RMI vs Sockets yet since I'm still battling with the lock strategy. However, I don't think that "the sockets are just a step in past". It's about having control vs giving control and is about scalability. You write your own protocol but how often will that change? I'd think the sockets are more scalable. For those where is specified the application might be used in WEB later, I see easier to NOT have a different server (RMI server) working in the background.
But I might be wrong...

Adrian
[ November 02, 2003: Message edited by: Adrian Muscalu ]

Hi Peter,
Calling lock() from update() was part of a test I made to prove a concept. In my implementation (for which I didn't write a single line of code yet) I'll have a Business Tier all right but the implementation will be slightly different.
Method isLocked(), along with lock() and unlock() will be called from the business tier on Data but they will have no direct implementation. They only dispatch to a LockManager class that is unique to all the clients. This is the place where the static vector will be in my case.

Does this result say us my program works fine?

Maybe. I don't see where you handled reentrancy. What happens if one record is beeing modified as another thread still waits for it? Once the latter will get his chance (and lock it accordingly), will modify a record that might not match the one a client viewed on the interface as result of a previous query. What if was deleted or booked in the meantime?
How can your unlock() implementation throw RecordNotFoundException? In the example you've provided there is no way. Unless you are just trying to prove a concept and the code is only an example.
Regards,
Adrian

Hi Andrew,

Andrew:
So as I understand this, your Data.update() method calls Data.lock() itself. In which case there is no value in Data.lock() being public. (But it has to be, since that is the signature in the interface - why do they have such an method signature then?)
Adrian:
My Data.update() calls indeed Data.lock() but the latter only dispatches to the lock() method of the LockManager class. It is this class that handles all the locking process and every instance of Data has a reference to it.
Andrew:
But can some other method in the server (or from the client) also call the Data.lock() method?

The client has no way to call it directly since I'll be having a Business tier in place and for the client only a method of type bookRecord will exist. Theoretically, the server can call lock() directly because the method is still public (I can't do anything about it). What I can do is to remove completely the functionality from the lock() method. The modify() method will call directly the lock() from the LockManager. This way I avoid any confusion.
Regards,
Adrian

Well said Andrew, in this case the specs are clear. The implementation requires to wait.
Pep, good luck with it.
Adrian

Hi Andrew,
The link you've provided in the previous message had a strong impact on the way I intend to design. The thread was long, it took a lot to read but it worth it. I have no intention to go into details, I just want to say that my design fits in the 3-tier archiecture category. In other words, I consider myself part of the "Guinea pigs" team . While I understand your design I appreciate your determination to stick with the specs, I consider it not the best way to go.
Since in any design the client needs to make clear specs amd in this case the client is not to be found, I consider that he declined the invitation to discuss the details of the requirements. In this case I take a decision based on my professional expertise.

So as I understand this, your Data.update() method calls Data.lock() itself. In which case there is no value in Data.lock() being public. (But it has to be, since that is the signature in the interface - why do they have such an method signature then?)

My Data.update() calls indeed Data.lock() but the latter only dispatches to the lock() method of the LockManager class. It is this class that handles all the locking process and every instance of Data has a reference to it.

Client 1 believes that they have booked this Contractor and paid their money. Client 2 believes that they have booked this Contractor and paid their money.

Not exactly, at reentrancy each thread checks for deletion and for the booking status. This cannot happen.
What can happen (and my current design doesn't cover this yet) is that a client/CSRep modifies the name, location and other fields of a record while another one waits to re-enter. Since I only check for deletion and booking, the client might book a contractor that moved to a different location. I'll think about this.
I'm sure that whatever design will choose, we'll meet at the other side.
Phil, you've made an excellent case in that thread.
Regards,
Adrian

Hi Perogi,
I wonder how you pronounce that.
Threads vs RMI deserves another thread so if you are so kind to start it I promise to give my 2 cents.
A+
Adrian

I am not sure what reentrant means but once an object/client gets a hold on a record it checks if the record is still there. This is part of the lock method implementation.
It is also true that we might have the following situation: client1 is modifying record1, client2 tries the same and waits. Client1 finishes job, notifies and client2 locks the object, modifies it. This is some sort of "dirty modify" because client2 just modified a record he doesn't know. Should we take this into account? Not for this assignemnt I would say. This locking is so well implemented in a real database. I think we are fine for the assignemnt if we just identify this situation and document it.
What do you think?
Adrian

Pep,
Don't worry, you'll be fine next time. You are not alone.
As Phil said, try to start this topic yourself on a particular aspect of locking.
Cheer up,
Adrian