• 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

connection factory

 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
can u plz help me how to make a connection factory class that return a unique rmi object for each rmi connection.
although of course i am having only one instance of the data class
thanks
walid
 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Hope this helps.
 
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello again Mag!
Is the code snippet you provided how we track which client has locked which record? If so, since this is done on the client, we need to pass this object as a parameter into the lock and unlock methods, right? That way, our lock code can persist who locked what, and our unlock code can ensure the person attempting to unlock the record is the current owner.
Do I have this right? Or is the client ID generated differently.
Thank you kindly,
Dave.
 
walid aly
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i am sorry but can u plz clarify more
i have in my design one class that extend unicast and implement the data interface that inturn extend remote interface.
i juyst run this class and bind it , and to this instance the clients connect
where should i add the factort with the factory method
and when will it be invoked
i really need ur help
thanks
 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Dave,
When and why can a client unlock a record that doesn't lock by itself?
 
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by walid aly:
i am sorry but can u plz clarify more
i have in my design one class that extend unicast and implement the data interface that inturn extend remote interface.
i juyst run this class and bind it , and to this instance the clients connect
where should i add the factort with the factory method
and when will it be invoked
i really need ur help
thanks


Hi,
If you want to implement a factory,the data server class which extends UnicastRemoteObject needn't be bound to the registry. Instead, create one more class named ConnectionManager or so which extends UnicastRemoteObject and should also have a Remote interface of its own. Bind this ConnectionManager to the registry. This instance will be looked up by clients. A call like getInstance() on the ConnectionManager returns data server class which u have already created. In this case each call to the ConnectionManager's getInstance() returns a new remote data instance to the client.
But as you have already noticed, we should have only one local data object. So classes should be designed in such a way that all the remote instances refer to the same local data object. So the method body of ConnectionManager's getInstance() should be somewhat like,
public RemoteDataInterface getInstance(){
return new RemoteDataObject(localObject);
}
So, for each invocation, a new Remote object will be created, but all of them refer to the same local data object. Hope you understood the idea.

regards Jacob
 
walid aly
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks alot for clarifing this to me
i have one more question

I have implemented already the ConnectionManager and created a unique RemoteDataObject for each connection ,but how can i get a refrence of this unique RemoteDataObject ,
in the lock method of class Data , i tried "this" but it returned a refrence to the same Data object. plz advice.
also did u change the signature of the lock method??, am i right in having the key value pair in hash table as recordnum,a unique RemoteDataObject ...
thanks alot for everything
 
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 walid aly:
I have implemented already the ConnectionManager and created a unique RemoteDataObject for each connection ,but how can i get a refrence of this unique RemoteDataObject ,
in the lock method of class Data , i tried "this" but it returned a refrence to the same Data object. plz advice.

You cannot get a reference to RemoteDataObject without passing it in, which would require you to change the signature. But this modified signature goes against requirements and would cause trouble in local mode. You could also overload the lock() method. However I would suggest you do neither. I would contend that the Data class is the wrong place to implement locking.
Think in terms of responsibilities -- in a good OO design, every class has a single, well-defined responsibility. In my design, the responsibility of the Data class is to provide a local database implementation. Arguably, a local database is necessarily single-user and does not need locking. The lock() and unlock() methods can be simple placeholders.
- Peter
[ November 09, 2002: Message edited by: Peter den Haan ]
 
Dave Teare
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Daniel,
The reason we want to know the client ID in the unlock method is to enforce that only clients that obtained the lock on a record can free the lock. This may seem strange that a client would try to unlock a record they do not own, but it could happen if a client was behaving badly.
--Dave.
 
reply
    Bookmark Topic Watch Topic
  • New Topic