• 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

DataInterface: Methode close

 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
In the Submission Sun states the the client has to include a class with the same public methods as the suncertify.db.Data class.
My question is now: How do you handle the close Methode in the remote case?
In my design I use only one Instance of the class Data in the server environment. So if one client calls the close method the db will be closed and other clients can't access anymore.
Thanks
Pascal
 
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


So if one client calls the close method the db will be closed and other clients can't access anymore.


This is obviously not acceptable in remote mode.
You have several choices here:
-- leave the close() method empty for remote object
-- throw a "method not supported" exception when the close() method is called remotely

Eugene.
 
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:
You have several choices here:
-- leave the close() method empty for remote object
-- throw a "method not supported" exception when the close() method is called remotely

Are you just listing the options without worrying about their merit for now, or do you mean to say that the second choice is a defensible design choice? Because I would contend that it isn't.
The second choice would require the client to be aware whether the DataInterface implementation it was using was local or remote. This would point to a flawed understanding of the interface concept. Interface implementations should satisfy the substitution rule for inheritance: wherever you are using an interface, you should be able to use any implementation of that interface in exactly the same way. The Java compiler takes care of ensuring that this rule is satisfied at the language level, but it is often not appreciated that you as a developer must take care of ensuring that this rule is satisfied at the semantical level.
Read this thread for a discussion of the close() method in particular.
- Peter
[ January 15, 2003: Message edited by: Peter den Haan ]
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Peter wrote:
The second choice would require the client to be aware whether the DataInterface implementation it was using was local or remote. This would point to a flawed understanding of the interface concept. Interface implementations should satisfy the substitution rule for inheritance: wherever you are using an interface, you should be able to use any implementation of that interface in exactly the same way.


I absolutely agree. However, my point is that throwing a "method not supported" is as legitimate implementation as an empty method, or a method that actually does some work. For example, here is a javadoc for the getNameInNamespace() method in Sun's Context class:
"In naming systems for which the notion of full name does not make sense, OperationNotSupportedException is thrown."
By analogy, it doesn't make sense for a remote client to close the database on the server, hence the justification for throwing an exception.
Perhaps a method like this should not be in the interface in the first place (since it forces the implementing classes to provide a "fake" implementation), but that's a separate issue.
Eugene.
[ January 15, 2003: Message edited by: Eugene Kononov ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic