Lockmanger- singleton implementation /static creation & assignment in RMI server ?

[Vikas Sood]

Hi ranchers,
I have implemented my lockmanger as a singleton class.There is going to be only one instance of lockmanager used by all the RemoteData objects for servicing requests remotely.
But by having a lockmanger implemented using singleton pattern, am i not limiting my implementation to be just limited to a single datbase file (single table),should i not make a static instance of LockManger in my ConnectionFactory class where i am already making a static instance of Data class which is been passed to all RemoteData objects for database access.Doing the above will allow me in future implementaions have more database files attached to my remote server use a seperate lockmanger for implementing locking in them.
Am i correct in my assumptions above, pls comment as i am confused.Has anybody else followed this kind of approach.
VikasSood

[S. Ganapathy]

Singleton implementation of lock manager means by providing all static methods or getInstance() method?
Regards,
Ganapathy.

[Vikas Sood]

Hi Ganapathy,

Singleton implementation of lock manager means by providing all static methods or getInstance() method?

Singleton implementation of LoackManger means a class with private constructor and only way of retriving an object of this type is by means of the static getSingletonInstance() method.
I think i have cleared out your question.
VikasSood

[Andrew Monkhouse]

Hi Vikas,
You can probably get away with making a comment in either your code or your design document (or both) stating that an enhancement would need to deal with this. This does fall under the You Arent Gonna Need It (YAGNI) principal.
If you do want to handle it, you could make your lock manager a Multiton which allows a controlled but variable number of instances of a Singleton.
One way of doing this would be to have the getSingleton() method accept the database name as a parameter. Inside the lock manager, you track the database names, and keep one instance of the lock manager for each unique database name, which you can return from the getSingleton.
Does this help?
Regards, Andrew

[Vikas Sood]

Hi Andrew,
I understood both the points which you have made.But i think the other approach of mine explained above apart from the singleton/multiton approach which you have discussed, would also be appropriate in the FBN scenario as it does not require much of a change to achive it.
example:

 ...Data db = null;LockManager lm = null;
//constructorpublic FBNServer(String dbname) {    db = Data(dbname);
    lm = LockManager();
}
//implementation of the interface method
public RemoteDataInterface getRemoteDataInstance() {    return RemoteData(db, lm);
} 
 

How did you implement your LockManager,was it a singleton object.
Kindly Comment.
VikasSood
Mark - I edited your post to include carriage returns in your code so that the thread won't appear stretched out online.
[ June 09, 2003: Message edited by: Mark Spritzler ]

[HS Thomas]

Hi Vikas,
I am trying to follow this thread. It would help if the code snippets could be formed to stop having to scroll the page left and right.

Would you be able to correct this?
regards

[HS Thomas]

But by having a lockmanger implemented using singleton pattern, am i not limiting my implementation to be just limited to a single datbase file (single table),should i not make a static instance of LockManger in my ConnectionFactory class where i am already making a static instance of Data class which is been passed to all RemoteData objects for database access.Doing the above will allow me in future implementaions have more database files attached to my remote server use a seperate lockmanger for implementing locking in them.
Am i correct in my assumptions above, pls comment as i am confused.Has anybody else followed this kind of approach.

You are correct in your assumptions. There is an approach discussed at length in this forum where the ConnectionFactory creates a Connection object and LockManager specific to the data (file/table). The locks were held in the HashMap/WeakHashMap specific to each data resource. Hardly any change / synchronisation was required in the Data class for this implementation.
I am revisiting this area as my implementation is in between the old and new versions of the exam.
I think the idea is to keep it simple and do what you are comfortable with.
To my mind, having Singletons can mean you have to spend more time on synchronisation. Unless someone has come up with a way of synchronising in one/a few places which still allows more throughput with little waiting.
Searching on the back posts for Connection may be a good idea. Be open to new ideas.
regards
[ June 09, 2003: Message edited by: HS Thomas ]

[Mark Spritzler]

Just a side 2 cents and in the words of the immortal Peter Den Haan. "Singleton is overused".
You don't need to make the LockManager a singleton. Just have only one instance and one reference that gets passed to each client's Remote interface class.
Mark

[John Smith]

Just a side 2 cents and in the words of the immortal Peter Den Haan. "Singleton is overused".
You don't need to make the LockManager a singleton.
The immortal Peter Den Haan actually argues beyond that, -- it's not only that you don't need to make LockManager a singleton, but also that you should not make it a singleton, as it incorretly translates the business model into an object model. More specifically, nowhere in the requirements it states that db.db will be the only database used in the system, yet your LockManager singleton makes that exact assumption.
Eugene.

[Andrew Monkhouse]

Hi Vikas,
The code sample you provided would work admirably, even for multiple databases. And it does away with the need for Singletons.
As for your question: How did you implement your LockManager,was it a singleton object.
I did not have a lock manager in my final submission.
My lock and unlock methods in the Data class were extremely simple. There was no need to put in a lock manager.
Regards, Andrew
[ June 09, 2003: Message edited by: Andrew Monkhouse ]

[Vikas Sood]

Hi Ranchers,
Thanks, what i would have done without you guys be around.
Carry on the good work guys.My lockmanger is not going to be a singleton.

VikasSood

[S. Ganapathy]

What is the problem if you keep lockmanager as singleton? In new assignment, there is no need to provide lockmanager seperately. this can be part of Data.java. But one should be careful while accessing lockMap variable, which is to be synchronized. So in Data class, an instance of RAF, and an instance of Map are to be synchronized. There is a chance of deadlock if more than one variable is synchronized.
I made Data singleton, and LockManager, has only static methods(which is also variant of sigleton), ofcourse lockmanager need not be singleton.
So you judge in a better way for your implementation.
Regards,
Ganapathy.

[Vikas Sood]

Hi Friends,
Another thing which came to my mind is, that i dont need the data and lockmanger instance to be static in the Remote server class, as i am passing a reference of the two manually to data class.
VikasSood

[S. Ganapathy]

Remote server is a wrapper to data class. Also called adapter.
Data uses LockManager, if provided, and it is a containment relationship(Data has LockManager).
OK?

[HS Thomas]

quoted from Andrew Monkhouse's post:

I did not have a lock manager in my final submission.

Oooh ,do tell! As far as you are allowed to.
I did have my doubts about the need of a LockManager. But then was convinced otherwise.
The persuading argument was that if your client dies ( mourn ) you'd need to have some mechanism of tracking and releasing the lock, otherwise your database may be forever locked ( well until someone notices and does something about it).
How did you handle this scenario ? Some kind of time-mechanism ( i.e. a background thread sleeps and checks at intervals) ?
If I remember this was the other alternative.
Not very comfortale with Threads that's why I opted for the LockManager solution.
regards
[ June 10, 2003: Message edited by: HS Thomas ]

[HS Thomas]

Andrew , I see you've given your method in this thread.
need lock() be synchronized?
SO you'd agree that a LockManager would be ideal to handle releasing of dead client locks AND handling dead-locks ?
P.S. I didn't know that RMI had it's own lock and unlock methods. You learn something new everytime.
Actually, I quite like the idea of letting the Network interface handle network problems and the Database handle database issues. I am not sure if deadlock is a database issue. Seems more like a programmer issue.
regards
[ June 10, 2003: Message edited by: HS Thomas ]

[Andrew Monkhouse]

Hi HS

The persuading argument was that if your client dies ( mourn ) you'd need to have some mechanism of tracking and releasing the lock

Yes, but as I mentioned in the other thread, I am also tracking locks at the network interface. This allows me to ensure that a client can only unlock a record it has locked. Also when my RMI code's unreferenced or close method get's called, I have a list of what locks this client has outstanding, and I can unlock them all.
Again, this is easy to translate to other network protocols. The code doing the networking interface can work out for itself when / how it determines that a lock should be unlocked.

How did you handle [locks where the clients died]? Some kind of time-mechanism ( i.e. a background thread sleeps and checks at intervals) ?

A time mechanism is easy to do, and it means that you can respond to a client death in a more timely fashion. I did implement this, but decided that it was really outside of scope, so pulled it out. I just let unreferenced handle deaths for me.

SO you'd agree that a LockManager would be ideal to handle releasing of dead client locks ....

I agree that a LockManager could be used for release dead client locks. However I dont agree that it is ideal for this purpose. The problem with a LockManager is that you need to have some way of identifying the client to the LockManager. There are ways of doing that, and since we only have one network interface to worry about, that is simple. But I have frequently had to deal with multiple network interfaces in my C programs (usually TCP/IP, X25, and LU6.2, but occassionaly LU2, async, bisync, and MQ Series as well), and I am well aware that they have different ways of identifying the end point of the connection, and they are not always (or even often) compatible.
Where this could cause problems: say you started with a socket connection, so you decide to use the socket number as the unique identifier. So far so good. Then someone comes along and requires you to add RMI simultaneously with sockets. You cannot use socket number with RMI. You cannot use thread numbers, as they might clash with the socket numbers. Somewhere, you are going to have to do a rewrite. And then what happens if someone adds MQ to the mix? You have another way of identifying clients in that.

SO you'd agree that a LockManager would be ideal ... handling dead-locks ?

I agree that the Lock Manager is the ideal location for identification of deadlocks.
(Pedantic aren't I? )

I am not sure if deadlock is a database issue. Seems more like a programmer issue.

Detection of deadlocks / timeouts are a database issue. There is no way for the client to know that they are deadlocking with another client.
Both, fortunately, are outside scope for this project.
What to do if deadlock or timeout occurs should be left up to the client code, IMHO.

P.S. I didn't know that RMI had it's own lock and unlock methods. You learn something new everytime.

Ummm, no. It is not that RMI has it's own lock and unlock methods, rather that I had code in the lock and unlock methods that were exported as services in my RMI solution.
That is, I had a class (called DataRMI) that extended UnicastRemoteObject which had lock() unlock() criteriaFind() etc methods.
Most of them were just wrappers. They called the method in Data of the same name.
However the lock(), unlock(), modify() and delete() methods in DataRMI had extra functionality to handle locking. DataRMI also had the unreferenced() method to catch dying clients.
Does this make sense?
Regards, Andrew
[ June 10, 2003: Message edited by: Andrew Monkhouse ]

[HS Thomas]

Does this make sense?

I am afraid it does. Why didn't I think of that ...? No, don't answer.
Looks like you had a GUI , your extended Data class and very little in between (i.e you didn't have to pass references around a lot).
How does your solution ensure your Data class can be reused for any database or did you go opt for a cut-down Connection/ConnectionFactory solution? No, I see your DataRMI replaces this.
And you'd have DataMQ, DataSocket, huh?
As an afterthought ... using your extended Data class in local mode is there an unnecessary overhead ? I suspect in this case you used the Data class directly.
Last one, how does Unreferenced ,close give you a list of outstanding client connections ? I thought you'd just call Unreferenced and leave it there.

Simple and pretty neat! Well done, Andrew.
regards
[ June 10, 2003: Message edited by: HS Thomas ]

[Andrew Monkhouse]

Hi HS

using your extended Data class in local mode is there an unnecessary overhead ? I suspect in this case you used the Data class directly.

Technically I had my GUI which connected to a database connection factory which provided either a local or a remote connection. This connection conformed to an interface which defined all the public methods of the Data class.
When the GUI requested a local connection from the connection factory, it returned an instance of a wrapper class for the Data class. The reason for the wrapper was just because I didnt want to change the Data class to implement my interface. I could have done so just as easily though.
Instead of making the local connection "appear" to throw the same exceptions as the network, I chose to make the network connection handle all network exceptions internally, so that the GUI never realised that there was a network problem. Once again this fits into my philosophy of trying to hide anything that might be specific to a particular network interface.
Just in case I am confusing you with the idea of a database connection factory on the GUI side, I also had an RMI factory on the server side, which created a new DataRMI class for each connection.
Regards, Andrew

[Andrew Monkhouse]

Hi Ganapathy
Sorry, missed your questions earlier.

What is the problem if you keep lockmanager as singleton?

You can get away with it for the assignment. However as Vikas noted, having the lock manager as a singleton means that you can only ever have one lock manager, no matter how many databases are later used. So at the moment, your application just has a database of contractors. What happens if the same application later gets extended to have a database for suppliers and customers as well? A single lock manager for three databases is achievable, but it gets kind of ugly fast.
The other thing to be aware of (as the legendary (sorry, don't think he is imortal ) Peter den Haan would tell you) is that singletons are overused. Quite often they do not need to be used at all, but the programmer likes the idea of a singleton and it fits their immediate needs, so they use it. This often causes problems later in the software life cycle. For more information on overuse of Singletons, see the IBM article Use your singeltons wisely

Data uses LockManager, if provided, and it is a containment relationship(Data has LockManager).
OK?

So you only have one instance of Data class, and it has only one instance of LockManager.
This sounds perfect. And neither of them need to be singletons.
Regards, Andrew

[HS Thomas]

Hi Andrew.

Technically I had my GUI which connected to a database connection factory which provided either a local or a remote connection. This connection conformed to an interface which defined all the public methods of the Data class.

This sounds like the ConnectionFactory on the client discussed here before.And RemoteDataFactory on the server. Did your RMI Factory on the server have to extend UnicastRemoteObject also, seeing as DataRMI did this already ? Other than the latter I don't think it's that different from the solution discussed before.
In this case , you could have had a RMIConnectionFactory , MQConnectionFactory,SocketConnectionFactory, which could have used the same Connection object
(to hold details about database schemas, transactions etc - beyond scope of the assignment ) and have Data do file/table level methods only.
But I guess it's your call as to how you'd like to handle network errors, etc.
By wrapping , your trade-off is in saving having to implement interface methods...
regards
[ June 10, 2003: Message edited by: HS Thomas ]

[Andrew Monkhouse]

Hi HS

This sounds like the ConnectionFactory on the client discussed here before.

Yes. This is a very clean, elegant solution, so many here have used it.

Did your RMI Factory on the server have to extend UnicastRemoteObject also, seeing as DataRMI did this already ?

Yes, my RMI Factory extended UnicastRemoteObject. It had only one method (getDataRMI), and this was the service that was bound to the RMI Registry. the DataRMI class also extended UnicastRemoteObject, however it was never bound to the RMI Registry, for hopefully obvious reasons.
Since I didnt want DataRMI's methods bound in the registry, I needed to have the RMI Factory's method bound in the registry, which meant that it had to extend UnicastRemoteObject.
Did I just use circular logic to explain this?

...and have Data do file/table level methods only

That's my intention
Regards, Andrew

[HS Thomas]

Did I just use circular logic to explain this?

No. It's just me trying to fill in the gaps I'm missing trying to understand your solution.
What's different about your solution is that you've done away with the need for having a LockManager. You've taken it one level further and made it that bit more elegant IMO.

The question about not binding DataRMI to the registry. I guess you don't want to expose Data to a client directly.
:roll: But it would have to be exported wrapped within the RemoteObject in order for you to use Unreference in DataRMI . . The client can't get at the Data methods but RMI can to handle Unreference or close. It's been a while since I touched on this subject. Please correct me if I am wrong.
regards
[ June 10, 2003: Message edited by: HS Thomas ]

[Andrew Monkhouse]

Hi HS

The question about not binding DataRMI to the registry. I guess you don't want to expose Data to a client directly.

I dont want to expose DataRMI to a client directly. As with a good factory, the user cannot create / or get access to an instance of DataRMI themselves. They must go through my RMI Factory method.
You are right with why I wrapped the Data class in the DataRMI methods - it lets me use unreferenced and the locking paradigm previously mentioned.
Regards, Andrew

[HS Thomas]

Hi Andrew.
Thanks for your reply.
Is your solution based on any references ?
I'd like to know just how much can be added to the Network layer without it getting too unwieldy , if you get my meaning.
For example, if there were another object added to the network layer, say SessionManagementRMI for arguments sake, then would calling Unreferenced at DataRMI also remove references for Session Management ?
It adds to my comfort level if at least 3 other people advocate the same . ( I see you've submitted your solution(that's one), and passed with a good score(the examiner makes two, which would be enough for most people) but just point to another one and I shall be content with this and add it to my armoury or whatever you call a weapons hoard ). Any material you've based your solution on would be appreciated.
regards
[ June 11, 2003: Message edited by: HS Thomas ]

[HS Thomas]

Database locks
Well, searched on the WWW for RMI && unreferenced && layer and came up with the above.
Remember the immortal PdH.Does keep popping up from time to time.
Questions that arose reading the thread:
RMI cannot guarantee it uses the same thread when using Unreferenced.
The number of objects created [ at the network layer] may be an issue.
posted by Gennady Shapiro

while it's true that your thread IDs become invalide if your client loses connection and unreferenced() get called. But I do believe this is the whole point of using unreferenced() to clean up after dead sessions. This is how most commercial system work, HTTPSession is good example - you time out your session info is gone and you have to relogin (try explaining to Netegrity why your session info should be preserved after you time out ).
Also, I think RMI unreferenced timeout is 10 min or so (I could be wrong about this), if your client has to wait more than a few seconds for a lock there's has to be a bigger problem with the system.
Also, with increasing number of users you instantiate increasing number of objects and consume more and more system resources. That might not be a big deal for Fly By Night (I always thought it was funny how they named the project -- sounds like air carrier's operations system used to launch strikes agains Kabul), it could become a problem when number of user and complexity of objects grow.
Anyway, its a matter of choice

SessionManagementRMI may have been a good choice for arguments sake.
Is threads an issue when using RMI Unreferenced ?
Is number of objects created at the network layer an issue ?
How did you handle this in your documentation.

P.S. I don't mean to be an absolute pain but this could be a VERY fine solution if all questions were nailed.
regards
[ June 11, 2003: Message edited by: HS Thomas ]

[Andrew Monkhouse]

Hi HS

I'd like to know just how much can be added to the Network layer without it getting too unwieldy , if you get my meaning.
For example, if there were another object added to the network layer, say SessionManagementRMI for arguments sake, then would calling Unreferenced at DataRMI also remove references for Session Management ?

I dont like your example, as one of the main reasons for implementing a session manager is when network connectivity cannot be guaranteed, in which case you would not want to be using unreferenced to remove old locks.
Even if you are just dealing with message sequencing issues then you would have to set up a complete protocol for message sequencing, which would pretty much invalidate having the DataRMI class exposed.

It adds to my comfort level if at least 3 other people advocate the same .

I advise against following a particular design just because someone else used it. You have to be comfortable with why it was designed, and be prepared to defend that in your design decisions document and possibly in the exam. Only use a particular design if you feel you can defend it yourself.
Having said that, my design is pretty much the same as Mark Spritzer's (another high scoring SCJD) as described in this thread. Funny thing though, when I first read Mark's post, I didnt understand it, and decided against it because I didnt understand it. Later, following other threads in JavaRanch, and from other RMI tutorials, I developed an almost identical solution (re-inventing the wheel). It is only now that I have gone back and read Mark's solution that I can see how similar they are. One result of me having developed it myself is that I do defend it on extensability grounds, whereas I dont recall a post from Mark defending his solution on those grounds.
Regards, Andrew

[HS Thomas]

Hi Andrew,
Obviously you have spent a great deal of time analysing your design and your score was well deserved.
You've just given me the 3rd person - Mark. I shall be content and pursue this train of thought.

I advise against following a particular design just because someone else used it.

You may not have a choice if you walk into a job and find it has been set in concrete and that design is what you have to work with. Very little time given for re-inventing the wheel on the job. At least with practise you know what you are working against. Imitating gurus who concur does reduce the burden. So nice of you all to share your designs.
Thanks Andrew.
You've been a lot of help. Now I have to find enough arguments to sway my design between the LockManager solution and your independent re-invention of Mark's.
regards
[ June 11, 2003: Message edited by: HS Thomas ]

[Qusay Jaafar]

So, DataRmi extends UnicastRemoteObject and RmiFactory extends UnicastRemoteObject.
is DataRmi implements DataInterface and I think it is the case, but what RmiFactory implements?
DataInterface ---> DataAdapter ----> Data
DataRemoteInterface ----> DataRmi
(Here DataRemoteInterface extends DataInterface and Remote)
???Interface ----> RmiFactory
(where ???Interface extends Remote)
Did I miss something here?

[HS Thomas]

Hi Qusay,
If I understood correctly, the only method in RMIFactory was getDataRMI.
The RemoteExceptions were never thrown up to the GUI , but handled internally. Perhaps there was a general Exception message.
I think that's the only reason you'd need the Remote interface, isn't it ?
posts by Andrew :

Instead of making the local connection "appear" to throw the same exceptions as the network, I chose to make the network connection handle all network exceptions internally, so that the GUI never realised that there was a network problem. Once again this fits into my philosophy of trying to hide anything that might be specific to a particular network interface.

But looks as though Andrew implemented an interface conforming to the Data public methods.

Technically I had my GUI which connected to a database connection factory which provided either a local or a remote connection. This connection conformed to an interface which defined all the public methods of the Data class.
When the GUI requested a local connection from the connection factory, it returned an instance of a wrapper class for the Data class. The reason for the wrapper was just because I didnt want to change the Data class to implement my interface. I could have done so just as easily though.

regards
[ June 11, 2003: Message edited by: HS Thomas ]

[Qusay Jaafar]

But RmiFactory extends UnicastRemoteObject.
Why is that. I think RmiFactory like that:

public class RmiFactory {
    private DataRmi dr;
    public RmiFactory() {
        dr = new DataRmi();
        // start rmiregistry
        // Namin.rebind(......)
    }
    
    /**
     * return DataInterface where client invokes methods for Data class
     */
    public DataInterface getDataRmi() {
        return dr;
    }
    public static void main(String [] args) {
        new RmiFactory();
    }
} // end RmiFactory class
but why RmiFactory extends UnicastRemoteObject?  

[Andrew Monkhouse]

Hi Qusay
Perhaps it would make more sense if I filled in some of the gaps in the code you tried:

public class RmiFactory {
//Andrew    private DataRmi dr;
    public RmiFactory() {
//Andrew        dr = new DataRmi();
        // start rmiregistry
         Naming.rebind("factory", new RmiFactory())
    }
   
    /**
     * return DataInterface where client invokes methods for Data class
     */
    public DataInterface getDataRmi() throws RemoteException {
// Andrew        return dr;
        return new DataRMI();
    }
    public static void main(String [] args) {
        new RmiFactory();
    }
} // end RmiFactory class

Do you see what I am doing? I am returning a new instance of DataRMI each time a user calls my factory method (getDataRmi()).
Since getDataRmi() is the RMI method the user will be calling, the class it is in (RMIFactory) must be the one bound in the registry, and must therefore extend UnicastRemoteObject (well, there are a couple of other classes I could extend, but this is easiest).
Regards, Andrew

[Qusay Jaafar]

and I think this suppose to extends UnicastRemoteObject, isn't it?

[Qusay Jaafar]

and suppose to implement Remote interface:

public class ConnectionFactory extends UnicastRemoteObject implements Remote {
    // the code mentioned above
}// end ConnectionFactory class  

otherwise:

ConnectionFactory cf = (ConnectionFactory)Naming.lookup(.....);

will throw exception...
am I missing something here?

[Andrew Monkhouse]

Hi Qusay
You are correct in both posts
Regards, Andrew

[Qusay Jaafar]

one more question please.
is DataRmi class the wrapper class for Data class?
that means:
( DataAccessFactory ---> DataRemoteAccess ) this is the client side, then
DataRemoteAccess connects to ConnectionFactory
( ConnectionFactory ----> DataRmi ----> DataInterface ----> DataAdapter ----> Data) this is the server side
Now,
( DataAccessFactory ----> DataLocalAccess ) this is the client side which returns ( DataInterface ----> DataAdapter ----> Data ) this is the server side.
to be more clear:
------------------------------------------------------>DataInterface---> DataAdapater---> Data
||
| ------------
DataAccessLocal|
^|-------------------------
||
||
DataAccessFactory|
| DataRmiInterface
| |
---> DataAccessRemote ---> ConnectionFactoryInterface |
| |
| |
---> ConnectionFactoryImpl ---> DataRmiImpl
In fact this is my design, but I am facing NotSerializaitonException problem which click on "Network connection" button.
something wrong here?

[Andrew Monkhouse]

Hi Qusay
Sorry, I cannot read the majority of your post - did you foget to use code blocks or something?
Regarding your comment: but I am facing NotSerializaitonException problem. This is the problem you mentioned in this thread. As I said, this is because the class you are trying to return does not implement Serializable or the RMI classes.
The following code shows both valid ways of handling RMI, and the problem. Please make sure you understand what is going on before you use parts of this code in your assignment.

import java.io.Serializable;
import java.util.*;
import java.rmi.*;
import java.rmi.registry.*;
import java.rmi.server.*;
class NonWorker {
    public void doSomething() {
        System.out.println("We will never see this");
    }
}
class LocalWorker implements Serializable {
    public void doSomething() {
        System.out.println("Doing something on the client side");
    }
}
interface WorkerReference extends Remote {
    public void doSomething() throws RemoteException;
}
class Worker extends UnicastRemoteObject implements WorkerReference {
    // do nothing constructor
    public Worker() throws RemoteException { }
    public void doSomething() throws RemoteException {
        System.out.println("Doing something on the server side");
    }
}
interface ServerReference extends Remote {
    public NonWorker getNonWorker() throws RemoteException;
    public LocalWorker getLocalWorker() throws RemoteException;
    public WorkerReference getWorker() throws RemoteException;
}
class Server extends UnicastRemoteObject implements ServerReference {
    // do nothing constructor
    public Server() throws RemoteException { }
    public NonWorker getNonWorker() throws RemoteException {
        return new NonWorker();
    }
    public LocalWorker getLocalWorker() throws RemoteException {
        return new LocalWorker();
    }
    public WorkerReference getWorker() throws RemoteException {
        return new Worker();
    }
}

public class RmiQusay {
    public static void main(String[] args) throws Exception {
        // try and run as a server
        try {
            // start a registry
            LocateRegistry.createRegistry(1234);
            
            // bind our server app to it
            Naming.rebind("rmi://localhost:1234/RmiQusay", new Server());
            
            // tell the world we are running
            System.out.println("Server running");
        
        } catch (Exception e) {
            System.out.println("Exception swallowed: running client code");
            
            ServerReference remoteCode = 
                (ServerReference) Naming.lookup("rmi://localhost:1234/RmiQusay");
            
            WorkerReference myWorker = remoteCode.getWorker();
            myWorker.doSomething();
            Thread.sleep(2000);
            
            LocalWorker myWorker2 = remoteCode.getLocalWorker();
            myWorker2.doSomething();
            Thread.sleep(2000);
            
            NonWorker myWorker3 = remoteCode.getNonWorker();
            myWorker3.doSomething();
        }
    }
}

When you compile it, make sure you run rmic on both the RMI methods:

javac RmiQusay.java 
rmic -v1.2 Server
rmic -v1.2 Worker

Run it, and you should get output stating that the server is running. Leave it running.
Open another window and run it again. This time three things will happen:

class Worker will be instantiated, and it's method called. This class extends UnicastRemoteObject and (indirectly) implements Remote. Therefore RMI knows to run it on the server side. So you should see output on the server side.

class LocalWorker will be instantiated, and it's method called. This class implements Serializable, so RMI knows that the instance of it can be packed up and shipped to the client side. So you should see output on the client side.

an attempt is made to instantiate class NonWorker. This does not extend any RMI classes, nor does it implement Serializable. So RMI gives up in disgust, giving you an UnmarshalException caused by NotSerializableException.

If there are any questions about this, please ask them before using parts of this code yourself.
Regards, Andrew

[Qusay Jaafar]

Thank you Andrew,
everything is working fine and beautiful.
My problem was that I added another layer of decoupling between DataRemoteImpl and Data class and that which cause NotSerializableException happens just like NonWorker class.