• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Basic design...comments requested

 
Christian Garcia
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
  • 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
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • 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
  • Quote
  • Report post to moderator
Eugene,
Thanks for the response. I appreciate it very much.
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • 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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic