Matt Lobo

Greenhorn
+ Follow
since Nov 06, 2008
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 Matt Lobo

Hey All,

Quick follow up question kind of regarding this.

I have views in my application that are JDialogs and JFrames. I have helper classes that work on both (simple things like setting up titles, frame icons, etc) - the only common is that they are both java.awt.Window classes.

So is it bad to have a helper method like doSomething(java.awt.Window window)?

I interpret the "no awt" rule is that you shouldn't use awt widgets.

Thanks!
Matt
One final question.

In the approach you did - since your main GUI client only knows about the local service and not the remote service - what happens when you have a connection exception? Does it just not get caught?

I think I'll have my service through general IOExceptions which Ive seen some people done here. That way the GUI client doesnt know about the RMI remote exception but at least can pick up on service problems.
Oops.

UnicastRemoteObject.export(Remote, int)

Thats the one I'm supposed to use I think!
Thanks again for your support!

The post states that you don't have to extend the UnicastRemoteObject because in java 5+ it generates them for you, using the static UnicastRemoteObject.exportObject(Remote) method. But then the javadoc states.

"The static method UnicastRemoteObject.exportObject(Remote) is declared to return java.rmi.server.RemoteStub and therefore cannot be used to export a remote object to use a dynamically generated stub class for its stub. An instance of a dynamically generated stub class is a java.lang.reflect.Proxy instance which is not assignable to RemoteStub. "

So how does the class get automatically generated then?

What I did as kind of a middle ground was refactor my server code to delegate the creation of the client and server endpoints. In a child class I have it doing what you guys suggested. But I was only able to do this if I created a class that extends UnicastRemoteObject and the server endpoint. This works - but I don't like that I'd have to update a separate class if my interface were to change.

Thanks again,
Matt

Roel,

So basically your service interface extends Remote and throws all RemoteExceptions? And because in the "nonnetworked" mode you don't use the RMI object that's OK even though your service it directly coupled to RMI?
Hi All,

Likely my last question before I wrap up the assignment.

The instructions state that in the non-networked mode, the network code shouldn't be accessed at all. What I really don't like is having my interface extend remote and having all the methods throw the base IOException. If one abstracts away whether or not they are using sockets or RMI, then having the interface extend an RMI interface kind of defeats the purpose right?

So what I have done is made an interface for a "Server" class which the following methods



Underneath the implementation, hidden to the caller, is the RMI interface. There are three main classes.

1.) A dedicated RMI interface, call it RMIExecutor
2.) A dedicated Client Endpoint
3.) A dedicated Server Endpoint

Each time a caller wishes to make an object "remote" the underlying server implementation wraps that implementation in a Server Endpoint, which is a UnicastRemoteObject and implements the RMI interface (all standard RMI stuff...). It binds it to the name of the interface class type provided for later retrieval.

When a caller wishes to retrieve a particular object from the server, they do so by class type, and since it's an interface. I find the Server Endpoint under the class name. Here's the tricky part - since the retreival is based on a class type, which will be an interface, I create a java.lang.reflect.Proxy class for the interface, and use the client endpoint as the invocation handler. Then any invocation to the remote object goes to the invocation handler, which contacts the server endpoint through the RMI interface.

Theres definitely some benefits to doing it this way
1.) One central location for all remote interaction (through dedicated RMI interface)
2.) No need for an interface to extend or a class to implement any RMI interfaces.

Downsides are
1.) Its not exactly straight forward.
2.) Exceptions can still be lost so my interface still has to through the an IOException otherwise the Remote exceptions will fall back to my fault barrier (an uncaught exception handler for all Threads).

So Im wondering trade offs. Have my interface extend Remote and then have a dependency which would kind of make my Server interface a moot point, or have something thats somewhat complicated and explain it in my choices. I guess I just liked having the actual server implementation under the hood but it looks like most people don't care about that in terms of their projects.

Thanks again for the support!
Matt
The record isn't "magically" disapearing. The delete(..) method is being invoked on that record. It's actually being manually deleted. Again, ignoring underlying implementation - because yes without calling unlock your cache will still have a lock recorded for that record so the record exists in terms of the cache but it doesnt exist in terms of persistence. That's just implementation and its not necessarily what the instructions indicate.
Thanks for the replies.

Im not sure about everyone elses instructions for the assignment but I have to think they are similar about this. As I said earlier, mine specifically states that if a record does not exist, the RecordNotFoundException should be thrown for the unlock method.

This problem is regardless of underlying implementation of your lock management, because I too have a cache of locks and owners so i know whats locked and what isn't.

What I was trying to say was in a typical delete function, let's say of record 5... a service level class would call:

1.) dbMain.lock(5)
2.) dbMain.delete(5)
3.) dbMain.unlock(5)

After step (2), record 5 is marked as a free space in the db file and considered "deleted". To the service, it doesn't exist in persistence anymore. Then at step 3, following the instructions of the assignment, we really should be throwing a "RecordNotFoundException" here because that record doesn't exist. At this point, I still have the lock recorded in my lock cache, but it doesn't change the fact that the record is gone.

The best thing I think we can do is if a unlock is invoked on a record that previously existed, and the one unlocking is the owner of said lock, then I won't throw the exception because the owner of the lock had to delete the record so they hopefully knew what they were doing.

Thanks again for the help,
Matt
Thanks for the reply!

After reviewing my instructions more carefully, I see that my assignment states: "Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file."

But we all know that: "Where this document uses the word "must" an absolute requirement is being described."

So I guess technically if I don't throw the exception in this case I won't get an automatic failure because the previous statement says that I "should" and not that I "must."

This will definitely be something I add to my choices.txt file.
Hi All,

I have a question regarding the expected results when a record is locked, deleted, and unlocked.

A record needs to be locked before its deleted. Once the record is deleted, the unlock should be called to release the lock on that record, but the instructions state that the "RecordNotFoundException" should be thrown when a record no longer exists. So in this situation, won't the unlock always throw an exception? And if so, is the lock ever really released?

Up until a few days ago, my implementation of the lock manager never actually threw those exceptions because its a logical lock on just an object (being an integer). So theres actually no tie to that and the record. I was fine with this but I dont konw how picky the grading will be if a record that doesn't exists is 'locked.'

Just wondering how other people handled this.

Thanks~
//Matt
Hi All,

I have a question and it may just be something that I've either created because of my implementation of the URLyBird project or perhaps it's just one of those undocumented issues that needs to be flushed out. I did some searching around the forum but didn't find anything and I hope this isn't a duplicate.

What I was wondering is in the networked mode, when you have 1 server running but 2 clients, if one of the clients books a room, how does the other client's GUI get updated?

I was thinking of doing some simple heartbeat that goes back to the server every to get the update data - but maybe this doesn't need to be considered? Of course, even with the heart beat approach theres still a chance that the CSR will try to reserve a room in the heartbeat window. But that can be solved with just a dialog to the user that the message .

My approach contains a service layer which returns exceptions like "NoSuchRoom" or "RoomAlreadyReserved" just incase the client and the server do get out of sync. In that case the client can get these exceptions and relay them accordingly to the user.

I really tried to figure out if this was scope creep, but the assignment clearly states that you have to deal with multiple clients locking a single server. So if theres multiple clients accessing the same data, theres going to be a chance of this happening.

Any guidance is appreciated.

//Matt
Any luck with this? I am having the same issue!
11 years ago
JSF