jefferson p

Greenhorn
+ Follow
since Mar 06, 2002
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 jefferson p

You're right, Mark - I noticed that when I took out the wait for the unlock...
Thanks,
Jeff
Thanks Sanjeev,
I mostly did it for consistency - basically, to have the same, but opposite, functionality as the "lock" method.
The reason it works (the current way) is because an unlock request always is made when the record is already locked (by the client who makes the request) - so it basically never waits anyway... In fact, I can't think of a situation where it wouldn't work...
Thanks,
Jeff
Hello,
I'm using the following snippet for locking:

and the opposite for unlocking:

Everything's working great - I've tested with multiple clients and clients that get a lock and crash... My question is if it's really necessary to block when you're just trying to release the lock???
Thanks very much,
Jeff
Thanks for the quick response, Travis,
I can't seem to get it to work without the export.
My RemoteData class has a reference to Data which is set in the constructor...

I can't figure it out... The data is somehow being sent across the wire and puking since it's not serializable... Aaaaghh!
Thanks,
Jeff
Hello,


There is only ever one object bound to RMI, that is your DataServer, which should only have one method. GetConnection() It returns a DataAccessRemote object which is only a Remote object, it does not extend Unicast...


I've messed with this for several days now... How can you return a DataAccessRemote object which "does not extend Unicast..." if it wraps the Data object (which is non-serializable)???
My version works with only the DataServer bound to the registry and both the DataServer and DataAccessRemote object extending UnicastRemoteObject (or if just the DataServer extends it and the DataAccessRemote is exported with the UnicastRemoteObject.export() method).
If the DataAccessRemote object does not extend UnicastRemoteObject than I get the "non-serializable" errors, which I would expect, since it then tries to send the Data object (which is non-serializable) over the wire.
I also have to have 2 stubs - one for the DataServer and one for the DataAccessRemote class - is this right??
Thank you,
Jeff
I'm not sure what, if any, UML tool people are using - I've been using a freebie at www.proxysource.com - it's called proxy designer, I think. It's no rational rose, but it's easy to use and good for basic UML diagrams, IMHO.
Jeff
After much thought, I've come to the conclusion that the confusion for me is due to how sublcasses declare exceptions. In normal inheritance, a subclass "extends" or provides "more" functionality than the parent class. In the case of exceptions, however, a subclass (or subinterface) can only throw "less" exceptions (only checked exceptions/sub-exceptions thrown by the parent class) than its parent class.
The RHE book says something to the effect of, "When it comes to exceptions, the design of a parent class must include exceptions that derived classes may throw, even though the parent class does not throw them."
So, why not just have one interface that extends remote, and throws database and remote exceptions?
Best,
Jeff
Thanks David!
Finally, I got it - sure seems easy once the lightbulb goes on (or flickers, in my case)
Whew - on to the UI now...
Jeff
Hello Everyone,
I'm new here and trying my hand at the dev cert. I'm exploring several approaches using rmi. Some things I don't understand here that have been driving me crazy -
1. if RemoteDataInterface extends the DataInterface AND remote, does it override the methods in DataInterface?
2. Do the methods in RemoteDataInterface throw RemoteExceptions?
3. When the DataServer implements RemoteDataInterface do the implemented methods throw RemoteExceptions?
Uggh - 4 hours last night driving me nuts!
Thanks and hello!
Jeff