Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

B&S: OK to assume lock(), update(), unlock() called from same thread?

 
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here is a paragraph from the book "Java RMI" by William Grosso. This is p. 97-98:

It used to be that socket allocation was a major resource limitation ... [details omitted] ... RMI solves this problem by reusing sockets. In other words, if a client JVM sets up a socket connection to a server JVM, then the connection is actually kept alive for a short period of time by the RMI infrastructure. If, after the client request has been handled, a second request is made from the same client JVM, that request will reuse the same socket connection. This means that the number of socket connections required by an RMI server is approximately: 1 + number of simultaneous requests.



And he says he goes into more detail about this concept later in the book, but I didn't actually read that part.

So that is the conclusion I reached after reading that paragraph. But, just because it's possible doesn't necessarily mean it's a good design. It does solve the client identification problem pretty easily, though.
 
author
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lara:

I see, I think I just misread what you said: indeed, RMI requests can share a connection (in fact, I think this is configurable via JVM parameters), but RMI servers cannot possibly share connection pools (I'd like to talk to the genius programmer that figures that one out)!!

What you were saying is that you are not concerned over the additional system resources and potential code complexity of opening up individual RMI remote objects (otherwise called servers) becuase your are concerned over uniquely identifing clients between lock and unlock? In order to avoid my misreading again, could you verify that this is what you mean?

Also, I couldn't help but notice from the other topic that youyr lock and unlock methods are within the scope of a single RMI method call (i.e. virtually identical to Michal)??

If so, let me know, I think you might benefit from further discussion about RMI thread handling or the thread renaming technique....

Reza

P.S.: I'm still concerneed that this thread is getting a little too long, but don't knwo the solution to this right now...
[ June 08, 2005: Message edited by: Reza Rahman ]
 
Lara McCarver
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


What you were saying is that you are not concerned over the additional system resources and potential code complexity of opening up individual RMI remote objects (otherwise called servers) becuase your are concerned over uniquely identifing clients between lock and unlock? In order to avoid my misreading again, could you verify that this is what you mean?



I wasn't concerned about the additional system resources just because from what I read, it didn't sound like the additional system resources were significant. I was concerned about identifying clients between lock and unlock and using separate RMI servers seemed to be the only way to handle it. And I am not certain that it is more complex either. Although I have to admit that the multiple server approach still feels a litte weird to me.

Good thing I was shopping, since that apparently prompted John to put up that diagram... not to mention the great shoes, but I digress Now I am thinking about the alternative technique where (if I understand it correctly), I only have a single RMI server, and this RMI server hands out Data objects (well actually, DBAdaptor objects) as part of its RMI interface. The thing is, I have read the SCJD exam book chapter about RMI, and I have also read the 1st half of "Java RMI". And in neither book did they seriously discuss the idea of an RMI Server handing back a return object which is a Remote object. I was trying to figure out how this would work last night (in addition to finishing up coding on my LockManager). It sounds like every parameter that the RMI Interface exposes has to implement either Serializable (I see lots of examples of that... in fact in "Java RMI" the author shows how to do your own serialization) or Remote.

Here is my guess of how it should work: The DBAdaptor class would look like this



This is in contrast to the RMIServer class which has a class signature like this:



So the DBAdaptor is a Remote object but (since it does not extend UnicastRemoteObject) it is not an RMI server. I actually think this is really neat.

Also, I couldn't help but notice from the other topic that your lock and unlock methods are within the scope of a single RMI method call (i.e. virtually identical to Michal)??

I am not 100% sure what you mean by this. I think the answer to your question is "Yes". My Lock() and Unlock() methods do not contain cookies. They are separate methods, but I was planning on having my RMI interface contain methods like "Book", "Partial Book" (in theory, if I'm not too lazy", etc., which wrap Lock() and Unlock() within business-oriented methods that hide the details of my server implementation.

I think you might benefit from further discussion about RMI thread handling or the thread renaming technique



I'm sure I would benefit... I wish I could contribute more. And... I don't know what the "thread renaming technique" is
 
Reza Rahman
author
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lara:

If you feel you will not benefit, stop me at any time...I think you are missing a very critical point that will make your code more maintainable/simpler in a single swoop...

1. Do you realize that the lock and unlock methods will be called from the same thread (via your RMI call).
2. As long as there are not concurrent threads running that refer to the same object instance (I can explain what this means if you don't already know), you can simply replace your reference to "Data" with a reference to the "current thread" becuase you really only care about uniquely identifying the client withing the scope of lock/unlock, right?

If the answer to both of these questions are yes (again, Michal went through all of this), let me know, I'll give you the last bit of information you need to establish the assumption for #2.

Reza

P.S.: You are on the right track about remote objects. If you are only concerned about the elegance of you code, export is nice, but in reality it will not give yuo a performace boost or avoid opening undue TCP ports per server...
[ June 08, 2005: Message edited by: Reza Rahman ]
 
Lara McCarver
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I guess I have heard enough doubts expressed in this forum about how RMI handles threading that I am a little wary of using the current thread as a proxy for a client ID. Your point about the way I am calling lock() and unlock() from a single thread is excellent, and yet... maybe the DBMain interface that Sun provides for us is intended to function on its own, i.e. if Sun put together some kind of automatic test program that used these methods in a slightly different way, it should still work.

Besides, I think that it is a good design for Data to carry the client identity around with it. In theory, in a future version of my B&S server (yeah, right!!) I could have a login method on the client, and the client's username could be the client ID (or at least part of the client ID). This would make the logging more meaningful.
[ June 08, 2005: Message edited by: Lara McCarver ]
 
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
LMcC: Now I am thinking about the alternative technique where (if I understand it correctly), I only have a single RMI server, and this RMI server hands out Data objects (well actually, DBAdaptor objects) as part of its RMI interface.

Yes, you understand it correctly. There is only one object bound to the registry, and that object serves as a factory. The client looks up that factory in the registry, calls the getConnection() (or getDBAdaptor, if you wish) method on that factory, and what happens next is nothing short of spectacular: you get back a unique remote object that represents the identity of the client. Subsequently, you invoke the lock/modify/unlock methods on that object. Pretty clever. I wish I were the first to come up with that.
 
Reza Rahman
author
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lara:

If you really like the RMI factory pattern, that is another story. However, if you are interested in evaluating an alternative, let me tell you the following:

The current RMI architecture you are trying to implement is only really somewhat necessary if you are using the thick client model (that is, your RMI interface will mirror your data access object interface one-to-one). In that case, you absolutely have to know which client your request is coming from (across RMI method calls) and there are not very many things to depend on other than separate remote objects (really servers without external name bindings).

I'll admit I bought into some of the ideas posted here about RMI thread handling (in fact, I reinforced it in my mind from the horrible experiences I had with the Windows native thread model; I wonder if the people posting those ideas were doing the same). Fortunately, I don't think those ideas hold up upon further inspection...

Don't get me wrong, there are still intricacies in RMI thread handling. Fortunately, you get a free pass on most of it by going the thin client way. I'd like to put those myths to bed once and for all. If you want we can open up another topic on it to make it more prominent.

"Automated testing" is yet another myth that just doesn't go away. Sun evaluates your overall solution and choices. Period. That is simply all there is to it. Besides, will your current data access object work on it's own without some help from the RMI factory pattern?

As to handling login, you really don't need the RMI factory pattern for that either. As I mentioned before, all you need is a client tracking mechanism. You can easily implement that by adding a client key to your request methods and cache that on the client proxy after the "login" method validates. Opening up servers are simply not a good way of handling client connections (speaking to the performance issues I've been putting off, imaing having 100 CSRs simultaneously opening up clients on a 100 different TCP ports...what a scalability nighmare!! - We can discuss this more to if you want)...

Hope this helps.

Reza

[ June 09, 2005: Message edited by: Reza Rahman ]
[ June 09, 2005: Message edited by: Reza Rahman ]
 
    Bookmark Topic Watch Topic
  • New Topic