Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Connection Factory

 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understand that a ConnectionFactory is required on the RMI Server so that it can issue unique connection to each client. This can later be used in the lockManager. However I am having a hard time understanding Connection interface and ConnectionFactory object.
If I have an interface Connection does the ConnectionFactory implement that interface? I am planning to have two type of connection factory one for Remote connections and other for local connection. The remote connection factory will inherit from UnicastRemoteObject, Remote & Connection interface. The local connection factory will only inherit from Connection interface.
Also where will unreference factor in?
Please comment on the design above.
Thanks
-Amish
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Amish Patel:
If I have an interface Connection does the ConnectionFactory implement that interface?
No. The factory creates objects that implement the Connection interface. Of course, the factory will be a server-side, RMI-callable object, so you will have to define a remote interface for the factory as usual.
I am planning to have two type of connection factory one for Remote connections and other for local connection.
Overkill. This is the Abstract Factory pattern; it would be appropriate if the application would need to create multiple connections as it runs. It doesn't. It only ever needs a single connection which can be created at startup. All you need is a factory method (or, if you wish, a factory object) which can return either a local Data instance or a remote Connection it has obtained from the ConnectionFactory.
Also where will unreference factor in?
Don't worry about it for the moment. It is strictly a "nice-to-have" to help clean up if a client crashes. Right now it would just obscure the design which you're only starting to get to grips with.
- Peter
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Peter,
I am a little unsure now about the factory design that I am planning to use.
You said that I do not need RemoteConnectionFactory and LocalConnectionFactory because I only need connection one time. You are right, however are you saying that the ConnectionFactory does not extends UnicastRemoteObject? I had an impression that RemoteConnectionFactory should extends UnicastRemoteObject. SO now according to you ConnectionFactory implements Remote & is the only class I should use which will issue either RemoteConnection or LocalConnection.
Please comment.
Thanks Peter!
-Amish
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Amish Patel:
You are right, however are you saying that the ConnectionFactory does not extends UnicastRemoteObject?
No, I'm not trying to say that. What am I trying to say? That's funny, people ask me that question all the time
The factory is a server-side, remote, RMI-callable object. The most convenient way to do this is to simply extend UnicastRemoteObject.
This factory will only ever produce remote Connections.
In addition, you have a different client-side factory method (or factory class, if you wish) that you call and which returns the right flavour of connection for you -- either a Data object instantiated locally, or a remote Connection object produced by your remote ConnectionFactory.
- Peter
[ January 24, 2003: Message edited by: Peter den Haan ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic