NX: Synchronization - those who passed??

[Terry Martinson]

I currently synchronize my basic Data methods that touch the files and deal with the file handle. (update, delete, create, find) I have singleton Data instance.
I do not synchronize my search type method in an effort to get a little more concurrency in the application. (search does call my find though, so a bit of it will be synchronized when it actually deals with the file)
I'm a bit paranoid right now and worrying about the famous locking deductions that everyone has been getting lately. I know that at least one of the folks that recently got a 44/80 did NOT synchronize his Sun-provided data methods, and still lost the 36 points.
Does anyone know of folks who have passed while sychronizing the methods rather than synchronizing on specific file handles?
Or is method synchronization just a bad approach and should be avoided?
Thoughts?
TJ

[John Smith]

It's meaningless to refer to a neighbor who failed the certification because he didn't synchronize a particular method in the Data class: I can think of a number of designs that are not thread safe even though all the methods in Data are synchronized, and a number of designs that are perfectly thread safe with none of the methods in Data synchronized. Vector is a simple example, -- just because it is a synchronized collection doesn't mean that the thread safety is assured when you use it.
You really need to understand how the thread safety is assured in your design. After you are satisfied with your theoretical foundation, run a practical test. Create 50 client threads, each incrementing a field of the same database record, 10000 times in a row, for each thread. If at the end of the test run the field is icremented by exactly 500000, in all likelihood you will pass the certification.
[ February 03, 2004: Message edited by: Eugene Kononov ]

[Bill Robertson]

Eugene,
Could you elaborate on what you mean by the following:
Create 50 client threads, each incrementing a field of the same database record, 10000 times in a row, for each thread. If at the end of the test run the field is icremented by exactly 500000, in all likelihood you will pass the certification.
I understand the 50 client thing and how to set up the threads and all that, but what do you mean by each incrementing a field? What field is incremented. Do you just mean changing the value of something like a booking field 1000 times. Its your use of increment that I don't understand.
thanks,
bill

[John Smith]

Bill: Do you just mean changing the value of something like a booking field 1000 times. Its your use of increment that I don't understand.
Yes, what you want to test is not just that a concurrent change is possible, but also that it yields the expected results. For example, if "booking" constitutes decrementing a field by 1, you want to make sure that if the current value is 10, then the two threads each trying to decrement this value will result in the value of 8, not 10, 9, or 7. However, since concurrency is unpredictable, you want to play with the law of large numbers on your side. Put a heavy load of threads on the same record, make them perform a million transaction on the same record, and compare the resulting field value with the expected result. For example, if each of the transaction is expected to decrease/increase the value of the field by 1, than the final value of the field must be decreases/increased by exactly one million.

[Bill Robertson]

Eugene, i totally got yeah. thanks