Originally posted by Alan Morgan:
Ok Yupp I think I understand you now.
I believe mine works the same but I have to run some tests later to prove it.
So do you have a section in your choices.txt on deadlock ?
And if so do you say something simple like
"Deadlock is avoided as only 1 client can lock 1 record at any 1 time
This is acheived as the client blocks on each request...."
or something along these lines ?
Thanks again,
Alan.
Originally posted by Alan Morgan:
Ok so I ran my tests and it seems that the blocking is working in the same way for me.
I put a bit of code into my server so that if you try to lock record 1 it hangs effectively.
So with the same client you can't do anything as the result is being waited on.
This tells me that if my lock/unlock occurs in one call from a client then a client can only lock one record at a time.
Just to check I had a second client connect to the server and try to lock record 2 and that worked fine.
How does this sound ?
Originally posted by Ronald Wouters:
In my URLyBird implementation, when starting the URLyBird server, the user is also shown a "server gui" where they must enter the location of the database file (JFileChooser, on the server machine) and also a port number on which the RMI registry will listen. These properties are also saved in the suncertify.properties file so the user doesn't have to enter them the next time they start the server.
Originally posted by Alan Morgan:
Yupp - After having a read of this thread
https://coderanch.com/t/187162/java-developer-SCJD/certification/Dealing-Deadlocks-Stale-Locks
I got to thinking about what you said again.
In this thread John Smith says:
So its seems to me (correct me if I am wrong) that he took the same approach as you.
One question - how exactly do you "block until the record is booked" ?
Oh nearly forgot - are you fat or thin client ?
So is your book() call on the server or client and do you think it makes a difference either way ?
Thanks again,
Alan.
[ March 15, 2006: Message edited by: Alan Morgan ]
Originally posted by Alan Morgan:
Damn that devil and his advocate...he's right again, which means more work for Alan![]()
You're right, what I will do is have the Data.lock method which invokes LockManager.lock check if the record is still valid after the lock is received.
If not I will release the lock and throw a RecordNotFoundException.
Good catch.
Have you started thinking about deadlock avoidance as yet ?
If so any chance you could have a look at the conversation Yupp and I were having above and throw your two-cents into the mix.
You're a useful man to have around....as yet untouched by the evils of coding, so I can get a "pure" opinion off you![]()