• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

RMI vs. Sockets

 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi mask ,
please read my previos post (passed 148/155) i've listed out five points listing out the advantages of RMI over sockets.

amjad
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My take on it was:

  • 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).]
 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
reply
    Bookmark Topic Watch Topic
  • New Topic