Tottenham Hotspur - Pride of North London
SCJP 1.4, SCJD, OCE EJBD 6
Originally posted by Herman Scheltinga:
hi Matt,
I am reading "SCJD Exam with J2SE 5" and it says on page 151:
"The RMI specification states that there are no guarantees about which threads will be used for any given remote method."
So I think using Thread.currentThread().getID() won't help you.
The autors give a solutions later in the book, but I haven't read that yet.
Herman
SCJP<br />SCJD
----------------------------------<br />| SCJP, SCWCD, SCBCD, SCEA, SCJD |<br />----------------------------------
Originally posted by Maurizio Nagni:
yeah... i agree, and implemented, to use a facade to create a more "human understandable" action BUT be carefull.
Suppose your book method in the facade class do the following
if you look at it carefully you will find that even if all the methods of the data class are synchronized book() is NOT! to this i found two solution
1) synchronize all the book() method.... unfortunately it create a slow down performance (yes.. ok... we do not have to care about performance)
2) wrap all in a new thread like
book() {
new Thread() {
void run() {
//yourCode
}
}
thread.start();
thread.join();
thread = null; //avoid memory leakage
}
please sorry the real raw format, but i would not be accused to pass code around
SCJP<br />SCJD
Originally posted by Maurizio Nagni:
well.... in a simple case if you have
if the second thread enter meanwhile i am doing "something" it will overwrite the lock value and when the first thread will enter in update... well.... CRACK!
what you say can be true in special situations but i preafer to have a global insurance
SCJP<br />SCJD
SCJP 1.4, SCJD, OCE EJBD 6
Originally posted by Maurizio Nagni:
I am talking about two different threads on two differents records.
The task of the lock is to forbidden two threads to operate on the same record BUT should be transparent if the threads are operating on different records.
Consequently the code I wrote in the previous post (lock, doSomething, update) require some kind of control because the lock stop the second thread if it want a record already locked not an available one.
SCJP<br />SCJD
Originally posted by Romeo Son:
Hi,
I have a question about the book method.
In the book you don't have also a read before update, to see if the ownerId field is empty or not? (if booking is alowed or not)?
SCJP<br />SCJD
SCJP 1.4, SCJD, OCE EJBD 6
SCJP<br />SCJD
Originally posted by Romeo Son:
Hi Mark,
I have simply synchronized the book method, so I do the read before the lock and I think it's OK also my approach, correct?
Romeo
SCJP<br />SCJD
Originally posted by Maurizio Nagni:
interesting the part about the fixed lenght record.... i didn't thought about it like an "autosynch" system
ok..ok... i tell you all the story....in my book method i pass as parameters, the record number and the ID of the user: the book method has to create a new record writing the userID which booked it and then pass it to the update(). It cannot be the update method to do that, it only write in the file; it must be done by the doSomething() method of the book() method.
the problem is not in the update but in the d = doSomething(); inside the book method. in the previous case, if T2 and T3 have the same value of "d" (bacause of the lazy T1) and supposing that when update method is available T2 start first, T2 will update a record that may be not what it wants but the cases can be many more... depend your implementation of the doSomething() (or more than just one doSomething)
ciao
SCJP<br />SCJD
----------------------------------<br />| SCJP, SCWCD, SCBCD, SCEA, SCJD |<br />----------------------------------
SCJP 1.4, SCJD, OCE EJBD 6
Originally posted by Romeo Son:
Hi Mark,
Thanks for your reply. I would have two comments, if I am permitted.
First, about the book method you posted. What happens if you try to lock record 100, that doesn't exists or you get a DataIOException thrown by your lock method? Then in your finally block you try to unlock a record that was never locked. Have you tested this situation, or what is your solution to this? I do in my finally block :
Second, I have thought about what you said about not synchronizing the book method.
Suppose Thread A wants to book record 0 and thread B wants to book record 1.
Suppose record 0 is already booked and record 1 is not.
A gets first CPU so it locks record 0 and reads record 0. Now B gets CPU and locks record 1 and reads record 1. At this time, A gets CPU again and continues from where it has been left, so it tries to update record 0 (remember, 0 it is booked in DB) with the values of record 1 (that is not booked in the DB).
Now A thinks 0 can be booked when in reality it can't be!!!
What do you think about this scenario? I am not convinced about your 100 threads, I think your approach would corrupt the data.
Please comment
Thanks!
Regards,
Romeo
SCJP<br />SCJD
SCJP 1.4, SCJD, OCE EJBD 6
Slideshow boring ... losing consciousness ... just gonna take a quick nap on this tiny ad ...
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|