Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

URLyBird 1.3.1 remoting

Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I'm currently designing the "remote" part of the application, and I'm facing a problem that has been often discussed on this forum but to which I haven't been able to find a staisfactory response.

I currently have one Data class, which does all the "low-level" database work, and a Facade interface, which defines more high-level methods (like "book" and "search").

The way I see it you have the following possibilities for the client to access the server:
- Bind 1 remote (Facade) object in the registry and have all clients use this object. You will have to synchronize all the methods in the Data class, since all clients will be using this one instance of your Data class and you can't read and write data at the same time. Synchronizing all the methods while using one object means you're doing database-level locking, which means only one read and/or write operation can happen at the same time. This will slow down things, and also removes the need for a custom row-based locking system. I don't think this is a good solution.
- A solution I've often heard is to use multiple Facade objects, which all share a common Data object. I don't see any advantage in this solution, and you're still facing the problems above.
- Use multiple Facade AND multiple Data objects. In my opinion, this is the only way to go. It's the only scenario in which a custom locking (other than synchronization) solution is really needed and clients can read/write at the same time (as long as they don't read/write the same record). You then need a static structure that keeps track of the locks on the database. You will also need to bind a factory in the RMI registry instead of a Facade object. It doesn't make any difference if you synchronize the methods in the Data class or not; each client will have it's own instance so the synchronization isn't needed.

For the people who have the Habibi book, he defends the 3rd solution on page 126 of his book, but the way he implements it isn't correct. He binds a single DVDDatabaseImpl (which is his Facade) object in the registry, which will then be used by all clients.

I'm eager to hear your opinions on this subject.

If you open the box, you will find Heisenberg strangling Shrodenger's cat. And waving this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic