• 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

Basic design...comments requested

 
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In thinking out my design I've come to the conclusion that it makes sense to omit the implementation of lock() & unlock() from the Data class. My thought here is that a version of the app that is running locally can simply use an instance of the Data class directly. There is no need to lock records. Given this, lock, unlock and criteriaFind would be implemented in my server-side, RMI based FBNDataServer class. Using this approach only requires an implementation for criteriaFind(..) within Data.
Adding 1 method and an 'implements FBNDataInterface' statement to the Data class sounds like a clean solution to the issue at hand.
Bring on the comments
 
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


In thinking out my design I've come to the conclusion that it makes sense to omit the implementation of lock() & unlock() from the Data class. My thought here is that a version of the app that is running locally can simply use an instance of the Data class directly. There is no need to lock records. Given this, lock, unlock and criteriaFind would be implemented in my server-side, RMI based FBNDataServer class. Using this approach only requires an implementation for criteriaFind(..) within Data.


This is certainly a valid design decision under very reasonable assumptions. This is how I did it, too. I did struggle about empty lock/unlock in Data and inability to run multiple threads in local mode under this implementation, but in comparisson to other aproaches it seemed to me the most simple and logical solution.
Eugene.
 
Christian Garcia
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Eugene,
Thanks for the response. I appreciate it very much.
 
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 Eugene Kononov:
[...] I did struggle about empty lock/unlock in Data and inability to run multiple threads in local mode under this implementation [...]

Such threads could still use Connection/RemoteData (whatever you called them) locally. Use the Connection class instead of its DataInterface you don't even have to catch RemoteException. The only disadvantage is that, if Connection extends UnicastRemoteObject, it will be exported behind the scenes -- not that it will make much difference in practice.
- Peter
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic