[NX]STuPiD questions HELP !!!!

[Peter Kovgan]

Locking description from "Contractors":
....You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server...
1. What means at most one program ?
a)Does it mean from 10:00:00 to 10:00:01 only client A has acess to program?
From 10:00:01 to 10:00:02 - client B...
b)Or it simply means that DB File opened to only one server program.
Only 1 server has access to DB file?
c)If b is OK,then does it mean that this server programm can open this file from several concurrent threads, or only one thread allowed open file in some period of time ?
Second question is more STuPiD:
Assume I've got some instance called DBProcessor for every client ,
this instance has method bookContractor(),
a)When I have 2 clients, every one has his DBProcessor instance on server side, when both clients call db_processor.book(), this functions work in separate threads or in one thread? Why?
b)If single client make in the same time two methods call:
db_processor.book() and db_processor.readAll(), does it mean
that 2 threads works? Or 2 methods work in 1 thread? Why?
Very strange for me, but I'm very confused by these stpd questions...
[ November 01, 2003: Message edited by: Peter Kovgan ]
[ November 01, 2003: Message edited by: Peter Kovgan ]
[ November 01, 2003: Message edited by: Peter Kovgan ]

[Peter Kovgan]

Is it better to create separate thread for all method invocation on server, for example:
book(){
(new BookThread(params)).start();
}
to be sure every method works in one own thread
(to be sure lock-do-unlock works in one thread)
?
[ November 01, 2003: Message edited by: Peter Kovgan ]
[ November 01, 2003: Message edited by: Peter Kovgan ]

[Jim Yingst]

1. (a) No - multiple clients may be accessing the server simultaneously.
(b) Yes.
(c) Either way is possible - it's up to you, depending how you wnt to write the one program that has access to the DB file.
2. (a) Depends how you chose to write the program. If you use RMI, and DBPRocessors are Remote objects, then RMI will probably create a thread pool to handle the different requests. In this case, you won't see the threading code yourself, but you have to write your remote classes to be thread-safe. If you use sockets, then any threads created will be under your own control, so it's up to you to decide if you want to create multiple threads to handle requests.
(b) How does a client make two simultaneous requests in the first place? This would reuire you to create multiple threads on the client. It's possible to do this, and indeed many professional-quality applications may do this for one reason or another, but I think most of us are keeping things simple by using only one thread on the client to make all requests to the server. In practice this is usually the event handler thread. Doing it this way mean that the client is basically paralyzed while waiting for the server to respond, but most of us find multi-threaded clients to be an unnecessary level of added complexity for this assignment.
However, regardless of what you do on the client, if you use RMI then you can't make any assumptions or guarantees about which threads handle which requests. If you have two consecutive requests from the same client, thay may be handled by different threads, or the same thread. If you have two conseuctive requests from different clients, then they may also be handled by different threads, or the same thread. If two requests are concurrent, then they can't simultaneously be handled by the same thread. But the system may simply make one request wait while the other is being handled; then handle the remaining request, all using one thread. Or it may use two different threads to handle the requests simultaneously. The RMI spec is deliberately vague about this because they wanted different implementors to have the freedom to choose whatever strategy they found most effective.
And again, if you use sockets rather than RMI, then all questions about how different threads work will ultimately be answered by you.
Is it better to create separate thread for all method invocation on server,
Using RMI this would be unnecessary. Using sockets, this is probably a pretty good strategy. Using a thread pool would be more efficient in the long run, but also more complex. Personally I would probably start with something like you're doing, and consider refactoring to a thread pool later on after the basic functionality had been implemented.

[Peter Kovgan]

Thanks a lot, Jim, very helpful topic.
But I still have doubt:
My client calls some method (book()) on server via RMI,
It's clear: all interaction between my comp and remote will be
RMI controlled and I can't do any asumption about threads , but
if this method(book()) creates another thread on server ?
client---stub-----NETWORK----server

//server side code:
book(){
(new BookingThread(params)).start();
}

class BookingThread extends Thread{
public void run(){
lock();
update();
unlock();
}
}

can I be sure this method will be executed by one thread?
Can I build my project on this basis? Or this is bad way?
Please, help me, this is very important to me...
Thank you.
[ November 01, 2003: Message edited by: Peter Kovgan ]

[Jim Yingst]

if this method(book()) creates another thread on server ?
client---stub-----NETWORK----server
//server side code:
book(){
(new BookingThread(params)).start();
}
First, thanks to RMI, there may or may not be a new thread created to call book() initially on the server. We don't know. Second, thanks to your code, yes there is definitely yet another thread being created within the book method. You wrote the code; you can see the thread being created. So I'm not sure what the question is.
I would say that if you're using RMI, there's no need at all to create new threads yourself on the server. RMI will create as many new threads as it needs. Adding further threads yourself is just confusing, and probably inefficient.

[Peter Kovgan]

OK, thnx.

[Peter Kovgan]

If you have two conseuctive requests from different clients, then they may also be handled by different threads, or the same thread. If two requests are concurrent, then they can't simultaneously be handled by the same thread. But the system may simply make one request wait while the other is being handled; then handle the remaining request, all using one thread. Or it may use two different threads to handle the requests simultaneously. The RMI spec is deliberately vague about this because they wanted different implementors to have the freedom to choose whatever strategy they found most effective.

So...If my function book() works in one thread, and another book() in the same thread, and both locks records, which one will do unlock()?,
Or I need some record-client_id massive to save rights of clients to unlock some record?

[Vlad Rabkin]

Hi Peter,

So...If my function book() works in one thread, and another book() in the same thread, and both locks records, which one will do unlock()?,

Honestly saying I think the case you described is impossible. As long as a thread on server (it is called "client thread") is owned by a client, it will not be given concurrently to another one (IMO). That is where I disagree with statements of Jim. It is possible that a client will get different client thread from RMI server, but it is impossible that one thread on RMI server will serve two different clients concurrently. It must first finish the client call. My statement may be wrong, but that is how I see RMI threading.
Best,
Vlad

[Jim Yingst]

Vlad - what makes you think we disagree here? I said:
[JY]: If two requests are concurrent, then they can't simultaneously be handled by the same thread.
so as far as I can tell we're in agreement here. I agree with everything in your last post, except your assertion that you disagree with me.

[Vlad Rabkin]

Hi Jim,

If two requests are concurrent, then they can't simultaneously be handled by the same thread.

I spent the weekend to agressivly ... Sorry, I missed "'t" . Sorry.

Best,
Vlad