The new I/O API

[HS Thomas]

Just out of curiosity , has anyone used the new I/O API in Java 1.4 (java.nio) and passed this certification or are they saving this for the new 1.4 Sun Certified Java Programmers ?.
I think they'll have it a lot easier.
java.nio has been described in Java in a Nutshell as being "an entirely new API for high-performance, nonblocking I/O and networking.
It has Client-side Networking capabilities, Server-side Networking ... The java.io and java.net APIs allow only blocking I/O so servers using these APIs must use a separate thread for each client. For large scale-servers with many clients , this approach does not scale well.The new I/O API allows most channels (but not FileChannel) to be used in Non-blocking mode and allows a single thread to manage all pending connections.."
" The FileChannel class allows Random Access to a file....has the ability to lock a file or a portion of a file against all concurrent access(an exclusive lock) or against concurrent writes(a shared lock)..."
Some questions as I return to my RMI, soon to be threaded solution :
1) Does one have to serialize the Random Access file in order to remotely invoke methods on it?
2)If so how does one do that? I've already implemented Serializable in the Data class but suspect the file is not implicitly Serializable.
3) Some of the methods in the Data class are invoked via Reflection from the GUI classes. I've come across some material that suggests this is not a good idea.
One bit of advice: if you are aiming to do the SCJD do it immediately after passing the SCJP. It helps with continuity.I passed the SCJP in 1999.

Notes from an aspiring ,bloodied and tearful Java Developer

[BJ Grau]

Can you elaborate more on what you mean about serializng the databse file?
Also, why are you using reflection?
[ July 03, 2002: Message edited by: BJ Grau ]

[HS Thomas]

Well,
I was led to change the Data class to implement Serializable and change the private instance RemoteAccessFile to static after a series of UnSerializableExceptions -- don't know why as I understood an object is serialized implicitly by RMI when marshalled.
I've finally managed to get the Remote Server to return data to a Remote Client.. (I tried changing it to transient , the logic behind this being I wouldn't want such a large object to be serialized anyway but it didn't even give me a Remote Object!!! )
I've been planning to remove invocation by Reflection to the Data public methods from the GUI since I read they are not such a good idea.
Do you think therein lies my problem?
Thanks

[Mark Spritzler]

HS
You shouldn't have to serialize the Data class. What you want to do is to set up an Object that resides on the server side for each client, that way the instance is only on the server and does not have to be passed to the client.
This is an example of a Proxy Object. Do a search on Connection Object and you should get lots of hits.
Mark

[HS Thomas]

Thank's Mark.
Would this be equivalent to a "Connection Object" ?
I had defined the following :
Remote Interface :
Remote Client : has the Naming.lookup() method
Remote Server : it implements the Remote Interface and contains the full implementation of the interface ( a combined ServiceProxy and ServiceImpl).
Unfortunately it also has a getData() method to return a reference (a Singleton) for the Data class for the following implementation of criteriafind to work
public Object[][] criteriaFind(String critmess, Data data) throws IOException ,DatabaseException ,
ClassNotFoundException , CloneNotSupportedException ,RemoteException
{ return data.criteriaFind(critmess,data);

[BJ Grau]

HS - I think you are getting close to using the Connection idea found in this forum. If that's what you are trying to do, try thinking about a Connection Factory class that is registered with the rmi registry, and it has a reference to Data. Then it has a method that the client can call, say getConnection(), that returns to the client a Connection object that has passed to it in its constructor a reference to the Data object in the Connection Factory.

[HS Thomas]

Thanks BJ ,
Correction to my last post:
The Remote Client has :
RemoteData data = RemoteDataFactory.getData();
and I did have a Factory called RemoteDataFactory
which does the Naming.lookup()
Naming.lookup(name);
name being an rmi URL to the RemoteData interface
What I'm dubious about is that after the line RemoteDataFactory.getData() which returns the interface type RemoteData I do a getData() on that to return me an instance of Data
which I pass to public methods in the client.
I suspect I should decouple the client to expect instead a type RemoteData . So RemoteData is the definition and Data is one of the implementations. I can remove the implements Serializable clause from the Data class and I won't get UnserializableExceptions ,hopefully.
(Interfaces are difficult - I've worked on a Java project where there wasn't a single business type interface just a few interfaces to hold constants. The penalties of not paying attention to OO design. If I get through this assignment that will obviously change )

[Eduard Jodas]

If I have understood well, you are trying to send Data objects from the server to the client.
You can not do that. A Data object represents a disk file by wrapping a RandomAccessFile. You can not transmit the db file over the network. This file must stay at the server in order to be shared by all clients.
Furthermore, you can not make the Data class Serializable because it is linked to a file. To make it Serializable you would need to make the attribute which points to the file transient. So, once deserialized, the link between Data and the disk file would be lost.
A possible workaround would be to create a FakeData class, which is used in the client and is connected "remotelly" to a Data object in the server. All the calls to FakeData methods are redirected to the server Data object.
Beware of static attributes that are not constants! They are the source of a lot of difficult-to-find bugs. Try not to use them.

[HS Thomas]

Thanks Eduard,
Quote -
"You can not transmit the db file over the network. This file must stay at the server in order to be shared by all clients."
The latter is what I'm aiming to design for. It's trying to get RMI to work accordingly. Forget the Serialization and static variable stuff - that was just a hack to remove the Unserializable Exceptions.
Trust me, my Remote classes look similar to the examples in the Sun Tutorials etc.
What is different is that in the RemoteClient I have a getData() method within my RemoteData interface to return an instance of Data to pass to the GUI. Notes posted on this forum suggest other people have done so as well.
Can anyone tell me why in the RemoteXXXX server class you bind to your RemoteXXXX interface that extends Remote? How does it know which Object you really want to access ? The Naming lookup
looks for the same RemoteXXXX interface....
Is there a rule 1 Remote server per Remote interface per Object ( if so why do ranchers have such generic names for their Remote classes as RemoteServer, RemoteInterface, RemoteClient )
Eduard, by FakeData class do you mean an abstract Data class ?? ... I hadn't thought of that..

[Eduard Jodas]

What I wanted to say is that your GUI classes can't have a direct reference to a Data object, because this Data object must reside in the server in networked mode.
You must have *something* instead which has the same methods as Data but is not Data. This *something* is what is directly connected to the GUI. In networked mode, when your *something* stuff gets a request from the GUI (modify, criteriaFind, etc) this request is translated to call a server object which in turn calls Data. In local mode, your *something* stuff may call Data directly:
Networked:
GUI -> *something* -> RemoteServer -> Data -> file
(RemoteServer extends UnicastRemoteObject and resides on the server)
Local:
GUI -> *something* -> Data -> file
The RemoteServer must have all the methods of Data but is not Data. This way it doesn't need to have a getData() method
The FakeData I told you in a previous post was just an example of *something*. It is not Data, and it is not an abstract Data either. It it a Proxy or Bridge that, in networked mode, translates GUI calls to remote calls.

Can anyone tell me why in the RemoteXXXX server class you bind to your RemoteXXXX interface that extends Remote? How does it know which Object you really want to access ? The Naming lookup
looks for the same RemoteXXXX interface....
Is there a rule 1 Remote server per Remote interface per Object ( if so why do ranchers have such generic names for their Remote classes as RemoteServer, RemoteInterface, RemoteClient )

You can have as many objects per remoteXXXX interface as you want. Just make sure you give them different names when binding them to the RMI registry. The Naming lookup doesn't look for RemoteXXXX interfaces, but for binding names.

[HS Thomas]

I think I've got it.Thank you all for your help (and patience )
The Proxy you mention is in addition to the RMI Proxy in the Remote Client i.e the _Stub class.
Is that correct?
This Proxy is deployed in the client.jar remotely as well as in the server.jar locally?
In networked mode it forwards requests to the server.In local mode it forwards requests to the original data class.
Is this a convenient place to put in a Locking/Unlocking strategy (which I still have to think through) or do I need another Proxy for that? I haven't even started on thread management. Would it be better to do this first ?

My new Proxy class is currently a static class with the same methods as in the Data class but static.