NX: Core distributed computing concept and locking
oli renard
Greenhorn
Posts: 28
posted 13 years ago
Hello,
this is my second posting since I received the instructions for my assignment about a week ago and I would like to thank those who replied so promptly to my very first posting.
I have not really started writing any code because I am extremely confused about the whole concept of the application and locking. Effectively, my understanding is that, regardless of the assignment, access to the database file must be done in a thread-safe manner. I have read several postings on JavaRanch regarding locking and invariably, the consensus seems to be that locking is not required in local (or standalone) mode but is required in server (or network) mode.
This seems fair enough, except that I cannot help thinking of a situation where the db file being used in local mode by user 1 is the same file being used in server mode by user 2. For example, let's say that I run the application on machine A in local mode and I specify my db file's location as on machine A. Then another person runs the server on machine B and specifies the same file as mine (i.e. on machine A) as their db file. Surely, since both users are accessing the same file, local mode must be written in such a way as to ensure that the data is updated in a manner which is as consistent as the server mode.
There has been discussion also on this forum about a LockManager to ensure thread safety when writing to and updating the database file. Again, I acknowledge the need for this. However, if a LockManager is used by the application, not the same one can be used in both mode. The server code runs in its own JVM and the application mode runs in its own JVM so how is it possible to write a single LockManager that ensures that database updates are done consistently across JVMs and that ensures a single point of entry to the database regardless of the mode that is being used, assuming that 2 different users are updating the same db file, but each user uses a different mode? This question may be due to my misunderstanding of RMI (which I intend to use for my solution), but in effect I believe that thread safety should also be garanteed in local mode, but I just do not know how this can be done with only 1 single LockManager being shared across different modes and JVMs? Or am I completely missing the point?
I have purchased 2 books for this assignment, the book by Mehran Habibi (from Apress) and the book by Alain Trottier (from Que, which by the way also states that locking is not required in local mode), but unfortunately neither has helped me to shed light on this, although Mehran's book is very good indeed and has clarified quite a few other things.
This question is also somewhat related to which code is deployed where. If local mode is used, one only needs the client and database code. To run the server, one only needs the server and database code. Assuming that these are installed on separated machines, the local mode application and the server will run in separate JVMs. Yet, they both specify a LockManager, but it will not work properly since these will be running in separate JVMs.
I believe that understanding this concept is key to my understanding of the whole application. I am sorry if this seems like an obvious question to some, but I just need to be 100% that I understand the concept. Thank you very much indeed for your assistance and help.
Oli
this is my second posting since I received the instructions for my assignment about a week ago and I would like to thank those who replied so promptly to my very first posting.
I have not really started writing any code because I am extremely confused about the whole concept of the application and locking. Effectively, my understanding is that, regardless of the assignment, access to the database file must be done in a thread-safe manner. I have read several postings on JavaRanch regarding locking and invariably, the consensus seems to be that locking is not required in local (or standalone) mode but is required in server (or network) mode.
This seems fair enough, except that I cannot help thinking of a situation where the db file being used in local mode by user 1 is the same file being used in server mode by user 2. For example, let's say that I run the application on machine A in local mode and I specify my db file's location as on machine A. Then another person runs the server on machine B and specifies the same file as mine (i.e. on machine A) as their db file. Surely, since both users are accessing the same file, local mode must be written in such a way as to ensure that the data is updated in a manner which is as consistent as the server mode.
There has been discussion also on this forum about a LockManager to ensure thread safety when writing to and updating the database file. Again, I acknowledge the need for this. However, if a LockManager is used by the application, not the same one can be used in both mode. The server code runs in its own JVM and the application mode runs in its own JVM so how is it possible to write a single LockManager that ensures that database updates are done consistently across JVMs and that ensures a single point of entry to the database regardless of the mode that is being used, assuming that 2 different users are updating the same db file, but each user uses a different mode? This question may be due to my misunderstanding of RMI (which I intend to use for my solution), but in effect I believe that thread safety should also be garanteed in local mode, but I just do not know how this can be done with only 1 single LockManager being shared across different modes and JVMs? Or am I completely missing the point?
I have purchased 2 books for this assignment, the book by Mehran Habibi (from Apress) and the book by Alain Trottier (from Que, which by the way also states that locking is not required in local mode), but unfortunately neither has helped me to shed light on this, although Mehran's book is very good indeed and has clarified quite a few other things.
This question is also somewhat related to which code is deployed where. If local mode is used, one only needs the client and database code. To run the server, one only needs the server and database code. Assuming that these are installed on separated machines, the local mode application and the server will run in separate JVMs. Yet, they both specify a LockManager, but it will not work properly since these will be running in separate JVMs.
I believe that understanding this concept is key to my understanding of the whole application. I am sorry if this seems like an obvious question to some, but I just need to be 100% that I understand the concept. Thank you very much indeed for your assistance and help.
Oli
Ken Krebs
Ranch Hand
Posts: 451
posted 13 years ago
Welcome Oli,
A remote user should not be specifying the database file on the server, only the location of the server it will use.
My assignment said:
I assume yours says something similar. Because of this statement, you don't need to be concerned with a local user using the same file as the server uses.
When you run in local mode on a particular machine, it will use its own local copy of the database file.
A remote user should not be specifying the database file on the server, only the location of the server it will use.
My assignment said:
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.
I assume yours says something similar. Because of this statement, you don't need to be concerned with a local user using the same file as the server uses.
When you run in local mode on a particular machine, it will use its own local copy of the database file.
kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
Javini Javono
Ranch Hand
Posts: 286
posted 13 years ago
Hi,
My instructions say something to the effect that I can rest assured that no other application--
and I may have implicitly assumed any application regardless of whether its running
on a local or remote machine--will attempt to use my database file.
So, I'm assuming that only one running application can have physical access to one
physical database file at a time; any other usage is illegal.
Thanks,
Javini Javono
[ January 20, 2004: Message edited by: Javini Javono ]
Originally posted by oli renard:
Hello,
This seems fair enough, except that I cannot help thinking of a situation where the db file being used in local mode by user 1 is the same file being used in server mode by user 2. For example, let's say that I run the application on machine A in local mode and I specify my db file's location as on machine A. Then another person runs the server on machine B and specifies the same file as mine (i.e. on machine A) as their db file. Surely, since both users are accessing the same file, local mode must be written in such a way as to ensure that the data is updated in a manner which is as consistent as the server mode.
Oli
Hi,
My instructions say something to the effect that I can rest assured that no other application--
and I may have implicitly assumed any application regardless of whether its running
on a local or remote machine--will attempt to use my database file.
So, I'm assuming that only one running application can have physical access to one
physical database file at a time; any other usage is illegal.
Thanks,
Javini Javono
[ January 20, 2004: Message edited by: Javini Javono ]
George Marinkovich
Ranch Hand
Posts: 619
posted 13 years ago
Hi Oli,
I agree with Ken and Javini that the problem you forsee is in fact prohibited by the assignment instructions. On a particular machine you will only have one of the following possibilities:
1) your application running in standalone mode
2) your application running in server mode
3) your application running in network mode, or
4) your application running in server mode and another instance of your application running in network mode (connecting to the data server on localhost).
I don't know whether 4 is really required, since the user could accomplish the same thing by 1, but I used the setup in 4 to perform preliminary testing of server/network-client operation of my application before testing on two different physical machines.
I don't think you have to worry about the case where 1 and 2 are running on the same machine at the same time, which I think was your original concern.
Hope this helps,
George
I agree with Ken and Javini that the problem you forsee is in fact prohibited by the assignment instructions. On a particular machine you will only have one of the following possibilities:
1) your application running in standalone mode
2) your application running in server mode
3) your application running in network mode, or
4) your application running in server mode and another instance of your application running in network mode (connecting to the data server on localhost).
I don't know whether 4 is really required, since the user could accomplish the same thing by 1, but I used the setup in 4 to perform preliminary testing of server/network-client operation of my application before testing on two different physical machines.
I don't think you have to worry about the case where 1 and 2 are running on the same machine at the same time, which I think was your original concern.
Hope this helps,
George
Regards, George
SCJP, SCJD, SCWCD, SCBCD
oli renard
Greenhorn
Posts: 28
posted 13 years ago
Thank you very much to all three of you for your responses. They clarify the fact that I will assume that standalone mode means exclusive access to my local db file and that I do not need to specify the db file location when I start the server.
However, I am still very confused about the other 2 modes, i.e. server and network modes. How are these different? What do you actually mean by "server"? Is it a database server or the RMI server or something else?
Can ypu please clarify?
Thank you very much
Oli
However, I am still very confused about the other 2 modes, i.e. server and network modes. How are these different? What do you actually mean by "server"? Is it a database server or the RMI server or something else?
Can ypu please clarify?
Thank you very much
Oli
George Marinkovich
Ranch Hand
Posts: 619
posted 13 years ago
Hi Oli,
I agree with the first part of your first sentence above, but I think you should think more about the second part (the bolded part). When you run in standalone mode you're planning to specify a local db file, right? If you don't specify a db file when you run in server mode, how will the server know where to find the db file? Then there's the question: when you run in network client mode do you need to specify the db file, or is that problem taken care of in a different way?
Imagine you have two machines, one of which will be called the server machine and the other the client machine. On the server machine you can start the server: java -jar runme.jar server. On the client machine you can start the network client: java -jar runme.jar. Somehow the server needs to know where the db file is located. Somehow the network client needs to know where the database server is located.
What is the server? Is it the database server or is it the RMI server or something else? My answer would be that the server is in fact a database server that makes available the database operations to a remote client (perhaps using RMI, perhaps sockets). So your database server sits on the server machine and waits to get a request from the client machine to do some database operation. Your network client sits on the client machine, and since it doesn't have a database of its own, performs its database operations by calling the remote database server. Does this make sense?
Hope this helps,
George
Originally posted by oli renard:
They clarify the fact that I will assume that standalone mode means exclusive access to my local db file and that I do not need to specify the db file location when I start the server.
However, I am still very confused about the other 2 modes, i.e. server and network modes. How are these different? What do you actually mean by "server"? Is it a database server or the RMI server or something else?
I agree with the first part of your first sentence above, but I think you should think more about the second part (the bolded part). When you run in standalone mode you're planning to specify a local db file, right? If you don't specify a db file when you run in server mode, how will the server know where to find the db file? Then there's the question: when you run in network client mode do you need to specify the db file, or is that problem taken care of in a different way?
Imagine you have two machines, one of which will be called the server machine and the other the client machine. On the server machine you can start the server: java -jar runme.jar server. On the client machine you can start the network client: java -jar runme.jar. Somehow the server needs to know where the db file is located. Somehow the network client needs to know where the database server is located.
What is the server? Is it the database server or is it the RMI server or something else? My answer would be that the server is in fact a database server that makes available the database operations to a remote client (perhaps using RMI, perhaps sockets). So your database server sits on the server machine and waits to get a request from the client machine to do some database operation. Your network client sits on the client machine, and since it doesn't have a database of its own, performs its database operations by calling the remote database server. Does this make sense?
Hope this helps,
George
Regards, George
SCJP, SCJD, SCWCD, SCBCD
oli renard
Greenhorn
Posts: 28
posted 13 years ago
George,
you are a star! You would not believe the extent to which your last paragraph has clarified things for me. However (there always seems to be a caveat in these things ;-)), can you please clarify these 2 things for me please:
1) When you want to run the application in network mode, you first need to start the server (using java -jar runme.jar server) and you THEN need to do java -jar runme.jar (without any argument) as a second step. In other words, these 2 steps go hand in hand. Am I right in thinking along those lines?
2) You quoted that
I apologise for my lack of understanding, but I just want to be comfortable with the issues at hand.
Thank you
you are a star! You would not believe the extent to which your last paragraph has clarified things for me. However (there always seems to be a caveat in these things ;-)), can you please clarify these 2 things for me please:
1) When you want to run the application in network mode, you first need to start the server (using java -jar runme.jar server) and you THEN need to do java -jar runme.jar (without any argument) as a second step. In other words, these 2 steps go hand in hand. Am I right in thinking along those lines?
2) You quoted that
The answer to the first senetence is that I can prompt the user to specify this when they start the server. As for the second, I am not sure. Can you please enlighten me on these 2 points please?Somehow the server needs to know where the db file is located. Somehow the network client needs to know where the database server is located.
I apologise for my lack of understanding, but I just want to be comfortable with the issues at hand.
Thank you
George Marinkovich
Ranch Hand
Posts: 619
posted 13 years ago
Hi Oli,
1) Yes, that's the natural order provider before consumer.
2) Your application in server mode is running on the server machine. Your application in network client mode is running on the client machine. How does the network client know from where to get the database server? Somehow it will need to know the host and port where it can access the database server. So in much the same way that the server needs to know where the database file is, the client needs to know where (host and port) the database server is located. Since we're prohibited from using command line arguments (other than the one specifically allowed), it seems that this information will have to be obtained from the client GUI.
Hope this helps,
George
1) Yes, that's the natural order provider before consumer.
2) Your application in server mode is running on the server machine. Your application in network client mode is running on the client machine. How does the network client know from where to get the database server? Somehow it will need to know the host and port where it can access the database server. So in much the same way that the server needs to know where the database file is, the client needs to know where (host and port) the database server is located. Since we're prohibited from using command line arguments (other than the one specifically allowed), it seems that this information will have to be obtained from the client GUI.
Hope this helps,
George
Regards, George
SCJP, SCJD, SCWCD, SCBCD
oli renard
Greenhorn
Posts: 28
posted 13 years ago
Thank you George, it is quite clear now.
Obvisouly, regardless of the mode there has to be a common interface to access the database. My intention was to provide a ConnectionFactory on the client side which would provide either a remote connection or a local connection (depending on the mode selected by the user). The connection returned would contain a reference to a database adapter. There would be a local database adapter for a local connection and a remote database adapter (which implements locking) for a remote connection.
Do you have any thoughts on this particular design?
Thank you
Obvisouly, regardless of the mode there has to be a common interface to access the database. My intention was to provide a ConnectionFactory on the client side which would provide either a remote connection or a local connection (depending on the mode selected by the user). The connection returned would contain a reference to a database adapter. There would be a local database adapter for a local connection and a remote database adapter (which implements locking) for a remote connection.
Do you have any thoughts on this particular design?
Thank you
, sounds good to me. 