Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX:Concurrent access to the data file problem

 
frank sun
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
It's about the new assignment of booking room.
Let's see this situation.
A remote client uses the data file through the RMI way, meanwhile, in the server machine, it's running one standalone mode client, and uses the same data file, most possiblly, they would overwrite each other, eg, both of them are creating a new record, because they are not in the same JVM, so they keep two copies of the data file information(eg, record number), possiblly, they would overwrite each other.
It's not the lock/unlock issues, because they are running in the different JVM.and there is not Flag field indicating where this data file is being used or not.
Could anybody teach me how to avoid that?
Thanks in advance!
Frank
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Frank,
You asked: Could anybody teach me how to avoid that?
Tell the user not to do it
I think we can do that safely - as long as it is well documented that you can only run one server or one standalone client at any given time then you should be safe.
If you do want to code for it, why not have your application (both standalone and server) try to create a "db.lock" file in the same directory as the database file, and delete it when the application shuts down? If the creation worked, then your application is allowed to work with the database. If the creation failed, then either there is another application running or the last application terminated abnormally.
There have been other comments in this forum suggesting that abnormal terminations are well outside of scope for us - the database could be corrupt, and we are very limited in what verification we can do.
So it would be reasonable to simply write a message to the screen (or display a dialog box if you are in GUI mode) saying that the lock file exists, and the user should get the system adminstrator to remove it if they believe it exists in error.
Other ways of getting around it are far more complex, especially doing it in a non system dependant way.
Just for the point of the exercise, I have tried to think about what could be done. Perhaps something like:

This is just random psuedo code, I have not tested it, and dont intend to test it Time delays are probably way too long - in real life I would probably make them much smaller. They have been given just to give people an idea of one way to handle it.
Regards, Andrew
[ May 01, 2003: Message edited by: Andrew Monkhouse ]
 
frank sun
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,Andrew
Thanks at first!
I think the first way, to create a db.lock file as the check condition when start another Data instance, is more suitable, because, when the new application running, the legacy system also need to access the data file, and the magic number may be taken as the check condition.
Best regards!
Frank
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Frank, don't your instructions say you can assume that only one program is accessing the database file at any one time? So it's either the server or the standalone client, and exclusive access is given to whatever programming is running.
-Barry
 
frank sun
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry for answering so late.
the below is from the instruction file:
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 thought I understood what you mean.
Thanks a lot!
Frank
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic