• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

database and user interface running in the same VM

 
Catherine McManus
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. Does this mean that I can have my client basically instantiate a Data object (in fact I will be using a wrapper for it), and call methods on it directly?


2. If that is the case, then how do I do the locking? It would be possible for two clients to start, in two seperate VMs, each using the same database file. I had thought (not very hard as yet) to do locking using some sort of synchronized methods or objects or something? This would be ok for a remote db where all access is done through one object.
This makes me think that point 1 is wrong. Is it?
Catherine
 
Paul Anilprem
Enthuware Software Support
Ranch Hand
Posts: 3820
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
>1. Does this mean that I can have my client basically instantiate a Data object (in fact I will be using a wrapper for it), and call methods on it directly?
Yes.

>2. If that is the case, then how do I do the locking?
The same way as you would do for a remote object but it won't matter because there is only one client.
>It would be possible for two clients to start, in two seperate VMs, each using the same database file.
You are right and in this case you can't help not corrupting the common db file.
But then this is reason why we need to have a server entity that brokers the requests to the database. So if someboady wants to have the functionality of multiple clients, then the db server and the client must be separated.
>I had thought (not very hard as yet) to do locking using some sort of synchronized methods or objects or something? This would be ok for a remote db where all access is done through one object.
Your concern is valid but you need not worry about two local clients modifying the same file. You have to realize that you ARE giving a solution to this issue by providing a remotly accesible db server. And this is why they ask for these 2 (local and remote) types of scenerios.
HTH,
Paul.
------------------
Get Certified, Guaranteed!
(Now Revised for the new Pattern)
www.enthuware.com/jqplus

Your guide to SCJD exam!
www.enthuware.com/jdevplus
Try out the world's only WebCompiler!
www.jdiscuss.com
 
Catherine McManus
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, Paul. Thanks for your advice.
Catherine
 
ruilin yang
Ranch Hand
Posts: 334
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am not sure what you said: " This would be ok for a remote db where all access is done through one object."
In network mode, do two separate clients use the same remote object or the same objects of different threads (effectively different objects) ? Does each request generate a separate thread (e.g. java servelet does so)?
Would anyone please give me some comments.
Best regards,
Ruilin
 
Glenn Opdycke-Hansen
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I created a class that handled just the locking function.
This can be tested by using Threads in main method.
The Data class then uses the locking class to use the locking behavior.

------------------
--glenn
 
Catherine McManus
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ruilin
As far as I understand RMI, when you bind the object on the server side, there is only one object. When a client does a Naming.lookup(), they get a reference to that one object.
My server only has one Data object. That is in a wrapper class, and an instance of this is the object that I bind.
In answer to your question :
In network mode, do two separate clients use the same remote object
or the same objects of different threads (effectively different objects) ?
I would say that the two separate clients DO use the same object on different threads. BUT although there are two threads, there is only one object.
And:
Does each request generate a separate thread (e.g. java servelet does so)?
Uuuh, not sure. I would expect it to. But I would like to hear from someone else on the subject.
Catherine
 
ruilin yang
Ranch Hand
Posts: 334
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Catherine,
Thanks for your response.
1) Each client has its own _stub class. In that sense, it may be
the case for each request effectively a separate thread is generated.
2) I like to clarify this point.
Any comments ?.
Regards,
Ruilin
 
Paul Anilprem
Enthuware Software Support
Ranch Hand
Posts: 3820
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

1) Each client has its own _stub class. In that sense, it may be the case for each request effectively a separate thread is generated.

I presume that you are saying, "each request effectively a separate thread is generated on the server".
1. By looking at a client side component you cannot say much about the server side, can you? To know whether multiple threads are created on the server, you have to disssect the server side framework/classes.
2. Whether multiple threads are created or not depends on how your framework (RMI/CORBA/DCOM etc) is configured. There are different options that a programer may want eg. a thread per request, a thread per client, thread pool. But such fine tuning is way out of scope for this project.
3. The straight answer to your question whether multiple threads are created for multiple requests is : May Be. And you should program your remote object assuming that it has to support requests in a multithreaded environment.
The reason is, most of the time the server framework creates multiple threads depending on the load. If you have 3-4 clients sending requests to the same server object, in all probability the framework will create multiple threads. On the other hand if load is low, the framework will keep just one thread.
HTH,
Paul.
------------------
Get Certified, Guaranteed!
(Now Revised for the new Pattern)
www.enthuware.com/jqplus

Your guide to SCJD exam!
www.enthuware.com/jdevplus
Try out the world's only WebCompiler!
www.jdiscuss.com
 
Conor Allen
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul,
Do you have any suggestions on how to determine/identify the client invoking a method?
I need to id the client such that only the client which requested the lock may release it ...
Any suggestions would be appreciated.
Conor
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic