• 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
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Henry Wong
Saloon Keepers:
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Frits Walraven

B&S Is RMI Connection Factory necessary?

 
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am working on networking part of B&S assignment.
According to Andrew's book, he uses RMI Connection Factory to generate different RMI client in order to have different client identification.
The reason to have different client id is that client can
lock and unlock a record by passing his id.
However, in B&S assignment, this cookie is returned by lock method instead of providing by client.
So, my question is, for B&S case, do I need to have RMI Connection Factory?

Lee
 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have the same doubt. I'm working on URLybird. The lock() method returns a unique cookie value so there is no need for factory to create a new identification object for each client. But it does not hurt to use factory pattern.
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Guys:- The assignment goes as follows: "If the specified record is already locked by a different client, the current thread ...". BY A DIFFERENT CLIENT. I suppose this passage means that we still need a means to identify the client before any cookies are prepared, thus the need for RMIFactory.

Or what?
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Alexei, I disagree with you.

The exact speicification goes as follows.
// Locks a record so that it can only be updated or deleted by this client.
// Returned value is a cookie that must be used when the record is unlocked,
// updated, or deleted. If the specified record is already locked by a different
// client, the current thread gives up the CPU and consumes no CPU cycles until
// the record is unlocked.

I don't think we need to identify clients as long as multiple clients are not able to lock the same record a tthe same time.
[ October 14, 2008: Message edited by: Anthony Choi ]
 
Ranch Hand
Posts: 169
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi all;

i agree with you Anthony Choi; however my assignment is B&S and lock return cookie, and i don't implement RMI factory. i think for my implementation it is not needed as i can identify my threads and client based on the return cookie value from lock method.

also RMI factory add flexibility for future improvement you can also do the same thing with out it and decrease the number of classes needed and the simplify the process of client connection as the client will only need to lookup for one remote object and also number of stub.

Best Regards.
Mohamed Darim Sulibi SCJP, SCJD in progress ....
 
Alexei Kopylov
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Anthony:-

Just think about a (weird?) scenario when THE SAME client tries (for some mysterious reason) to lock a record he (or she) has already locked some time before. Without client identification the lock() method would threat that call as an ordinary lock request; it would very soon discover this particular record being locked by a somebody, this leading to "give up the CPU and consumes no CPU cycles until the record is unlocked", effectively blocking the poor careless client from any other actions.

In my opinion the correct behavior would be just to ignore the erroneous request.

Where am I wrong?

/Alexei
 
Sunglasses. AKA Coolness prosthetic. This tiny ad doesn't need shades:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic