This week's book giveaway is in the OCP forum.
We're giving away four copies of OCP Java SE 8 Programmer II Exam Study Guide and have Kathy Sierra, Bert Bates, & Elizabeth Robson on-line!
See this thread for details.
Win a copy of OCP Java SE 8 Programmer II Exam Study Guide this week in the OCP forum!

Mike Youngstrom

Greenhorn
+ Follow
since Apr 17, 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 Mike Youngstrom

Evelyn,
Nevermind....I just tried to register again and it worked this time.
Thanks,
Mike
Evelyn,
This is Mike again from a few posts up. Do you have any word on what's up with my voucher number?
Mike
I just attempted to register and the Prometric lady didn't accept my Voucher #. If you're our ther Evelyn please help me. I sent you an email but haven't heard back. I don't want to miss my chance to take this test.
Regards,
Mike
hehe. Well, it's too late for RMI anyway. The main reason I used sockets over RMI in the first place is because I wanted to learn about the new non-blocking IO in 1.4. But I had to end that work because of the problem described above. Non-blocking IO holds no benefit if you have to have a thread for every client. So at that point it was easier to move to sockets than RMI.
Oh well, I think I'm submitting my program today so. Wish me luck.
If I don't pass I'll look into moving to RMI. (Even though I think my sockets and locking solution is pretty slick)
Mike
O.K. Thanks. I did add an isClosed method to my Facade interface and I implement the functionality of it in the facade and not in Data. So I should be O.K.
Thanks again for your help Mark,
Mike
Well, actually I'm trying to look for more/better reasons then the ones I have for not using RMI.
I'm not neccisarilly talking about the same thread associated with connections but A thread for each connection.....so if 5 people are connected will their be for sure 5 threads to handle those client's requests? With traditional Java network programming it pretty much is guarenteed....but with the introduction of the nio classes it's not.
So this is the question. Could this scenario possibly cause deadlock by using RMI?
Their are 6 clients connected to the RMI server and the server has allocated 5 threads to work with these 6 connections. Deadlock could occur if the following sequence took place.
1. Client 1 locks row 1
2. Client 2 attempts to lock row 1 but waits because it's already locked.
3. Client 3 same as client 2.
4. Client 4 same as client 2.
5 Client 5 same as client 2.
6. Client 6 same as client 2.
7. Client 1 unlocks row 1.
Now if 5 threads were allocated to the 6 clients then deadlock would take place because client 1 would never be able to unlock row 1 (step 7) because the 5 threads are being controlled by the other 5 clients.
Does that scenario make sence?
Thanks,
Mike
[ April 18, 2002: Message edited by: Mike Youngstrom ]
I was actually thinking it could be fairly useful for RMI as well.
In RMI doesn't the client use a Remote Interface to work with the Server where every method must throw RemoteExeptions?
So your invocation handler would translate your regular Data Interface method calls into method calls to the Remote Interface which would wrap the RemoteException catching.
Anyway, doesn't matter, I think it's about time to let this thread sleep.
Mike
Did anyone else add an isClosed() method to their Data class or Data Interface to help stop the client from sending commands to the database when it's been closed or shutdown?
Does anyone think it would be a bad idea to add the method to the Data class? Meaning do you think I'd be penalized?
Does anyone know if it's documented anywhere that for every connection to an RMI server their is a Thread not necissarily associated to the connection but will maintain a 1:1 relationship of connections to threads?
I'm asking cause I couldn't find that documented anywhere and I'd assume you'd need that when implementing locking.
Thanks,
Mike
O.K. Thanks for the comment, I'll consider removing it since it appears it may be too complex for a Jr. Programmer. I'm a little suprised that the use of InvocationHandlers(Proxy Classes) to implement Facades has not been discussed in this list before.
Just for future reference though maybe I'll provide a little more of a description of them for everyone.
A Proxy class is a class that dynamiclly creates stub (not RMI related) classes of an array of provided interfaces. It uses an InvocationHandler to process all the method calls of the Proxy class. (When you create a Proxy class you have to provide a ClassLoader I don't know what it's for either it's just in the example in the API docs)
Proxy Class API doc
The InvocationHandler Interface has a single method in it.

InvocationHandler API doc.
The Method passed into invoke() is the method called on the Proxy class. So if needed special handling can be provided for individual methods by checking the method passed into invoke() or the same code can be executed for all the methods invoked.
So in the case of facades the majority of methods called on a facade end up being simple pass throughs to the class being facaded. Or they all perform the same type of convertion to call the method on a remote object or something like that.
In the case of the Developer Assignment I'm using Sockets instead of RMI so every method called on the facade must be translated and trasmitted to the server in the exact same way. So the facade comes in handy because it makes me only implement the translation and transmission code once for all the methods of my facade interface. Which holds the following advantages.
1. Your translation and communication facade code becomes reusable. If any other interface were needed to be translated and communicated to a server the very same InvocationHandler could be used to do this with Zero new code.
2. Your code becomes more flexible. If a method is added to the facade interface then no new code needs to be implemented in your facade classes.
3. Less bug prone because their is zero code duplication.
Anyway, If anyone is interested in seeing how I used the InvocationHandler in my project just ask.
Thanks,
Mike
Thanks tons for the comment about #2 It's a huge relief.
As far as question #1 let me explain a little more how I'm using InvocationHandler.
Client get's an instance of Database using the DBFactory:
1. example remote database

or
2. example local database

Within the factory if the call is example #1 I do

The code for RemoteInvoker may look something like this.
(simplified)

Within the factory if the call is example #2 I do something like.

The code for LocalInvoker may look something like this.
(simplified)

The InvocationHandlers obviously get more complex once exception handling is put in but I believe because the client runs with the returned Database instance I'm staying true to the requirement of the user staying in one mode or the other. Or am I missing something? All the InvocationHandler does is simplify the creation of Database Implementation classes that might look like this:

Does that make more sence?
Thanks again for the comment,
Mike
[ April 17, 2002: Message edited by: Mike Youngstrom ]
Howdy all,
I've got 2 quick questions.
1. I'm using a Factory to obtain either a remote or local instance of a Database Interface for the abstraction of local and remote client interaction. I implement Database using an InvocationHandler and reflection to translate Database calls to local calls or remote calls. Does anyone think that an InvocationHandler is to complex for a Jr. Programmer? Techniclly I'm a Jr. Programmer and I understand them.
2. When I read the instructions to the assignment I got this idea in my head that the server would obtain a location for a db.db file when started up and that the clients would connect to the Server and share the db file the server loaded at startup time. So in other words I thought that if a client wished to open a local file it would specify a filename only and if it wished to connect to a server it would specify an address and port. (no filename)
But, reading other comments on this board it looks as though the server is supposed to obtain a filename from the client at connection time and use the client specified .db file.
Did I misunderstand the instructions or am I missunderstanding some of the comments on this board?
Thanks tons for your help,
Mike
[ April 17, 2002: Message edited by: Mike Youngstrom ]
[ April 17, 2002: Message edited by: Mike Youngstrom ]