I have problem finding good reason to why I choose RMI intead of Sockets. My only reason to why I choose RMI instead of Sockets is that I thought it would be more interesting to try a new technic. Please give me som feedback on the more technical approach to why you should use RMI instead of Sockets.
The requirement states that you need to develop a remote version of Data implementing the same interface. A socket-based protocol would mean that object would have to translate calls to the underlying protocol, and vice versa at the server end. RMI gives you this for free: the remote stub can be exactly the RemoteData implementation.
The RMI distributed garbage collection feature can be leveraged to clean up the locks of dead clients. With sockets you would have to explicitly expire the locks.
RMI has implemented the required multi-threaded server for you in an efficient way. To achieve comparable performance with a socket protocol, you would need to use thread pools and the like.
The first and second of these reasons are dependent on the fairly unusual design I chose. - Peter
[This message has been edited by Peter den Haan (edited July 18, 2001).]
hi Haan, If i want to use dgc to control the dead lock of the client, do i need to make DataInfo implements a remote interface? and another concern is that do i have to bind all the records when the server starts? thanks
Peter den Haan
posted 18 years ago
Originally posted by David Qiu: If i want to use dgc to control the dead lock of the client, do i need to make DataInfo implements a remote interface? and another concern is that do i have to bind all the records when the server starts? thanks
No. The database server implements the Remote interface, that's all. Everything else gets passed by value. (YMMV: in my particular design, I did not expose a database server, but a connection factory and a connection, both implementing Remote). - Peter
Well behaved women rarely make history - Eleanor Roosevelt. tiny ad:
Devious Experiments for a Truly Passive Greenhouse!