Data class -- synchronzed methods of it -legal or not

[Peter Yunguang Qiu]

The Data class must implements DACccess interface which provided by Sun.
Is it OK for me to sychronized some of the methods of Data class? such as:

public synchronized String[] readRecord(long recNo) throws RecordNotFoundException {}
public synchronized void updateRecord(long recNo, String[] data, 
long lockCookie) throws RecordNotFoundException, SecurityException {}
  

Because these methods' interface is specified by Sun, if I add "synchronized" to these methods it seems different from Sun's interface. Is it legal? (Sun is the judge). Is it good?
Anyone can give me help and explanation? Thanks.
Peter

[Nicholas Cheung]

Hi Peter,
You CANNOT change the signuatures of the methods that provided by SUN. Otherwise, your assignment will be regareded as "Automatically Fail", and you need to retake the exam.
Nick.

[Peter Yunguang Qiu]

:roll: Adding "synchronized" to a method, is it change the signatuer of the method?
Peter

[Nicholas Cheung]

Hi Peter,
The term "signature" I mean is the function declaration that SUN's provided. Think about the case, if you can synchronize the functions for accessing the database file, why we need record locking then? Since each function can only be called by one thread at one time, it is already thread safe, and record locking is redundant.
Nick.

[Terry Martinson]

Peter and Nicholas -
There are two different types of locking - the physical locking (deals with locking on the actual db file) and logical locking (for communication between threads/clients. Bharat gives a better explanation of this in this thread
You can synchronize the methods in the Data class, and it is talked about in lots of threads out here on the forum. Max also does this type of thing in his book.
See another thread of potential interest here and here
TJ

[Philippe Maquet]

Hi Peter and Nicholas,
Adding "synchronized" to a method's signature DOES NOT modify the signature. Synchronization is implementation-level stuff.
And BTW, think of the fact that the "synchronized" keyword used in the method signature is just a shortcut :

public synchronized void method() {
}

is equivalent to :

public void method() {
    synchronized (this) {
    }
}

Regards,
Phil.

[Nicholas Cheung]

Hi Phil,
But then, when SUN tests the our system using software, will it regard the following 2 as equivalent?

public void method() {...}

and

public synchronized void method() {...}

In order to avoid (or in fact I dont wanna bet on whether SUN accept), I prefer NOT to change the method declaration provided by SUN. And in the old assignment, as limitation is not that much (compare to the new one), I think it is less restrictive in the past.
In addition, Terry, as there is no *complusory* interface that Max's example needed to implement, his system is free to implement in any direction. If you regard that system, Max can even throw IOException whenever it encountered, however, we cannot do so (at least cant do directly) since the exception thrown is bounded by SUN's requirement.
Nick.

[Andrew Monkhouse]

Hi Nicholas,
Phil is correct. Adding the synchronized keyword to your implementing class does not change the method signature.

Java Language Specification -> Interfaces -> Abstract Method Declarations
Note that a method declared in an interface must not be declared native or synchronized, or a compile-time error occurs, because those keywords describe implementation properties rather than interface properties. However, a method declared in an interface may be implemented by a method that is declared native or synchronized in a class that implements the interface.

Regards, Andrew
[ January 04, 2004: Message edited by: Andrew Monkhouse ]

[Nicholas Cheung]

Hi Andrew,
Yes, I understand that adding the synchronized keyword does not change the signature, but here, if we add that keyword, the *defintion* of our interface is differ from what SUN gives us. In such, does this accept? (as we are expected that not to change the given interface provided by SUN).
In addition, if we do that, even we do not implement the record locking, it wont cause any problems becos NO two threads can access the same database file at one time, and this assure that NO two threads can access the same record at one time.
Nick.

[Barry Gaunt]

Consider this code:

 
public interface A // provided by Moon
{
    public void aMethod();
}

public class B implements A // provided by you
{
    public synchronized void aMethod()
    {
         // do something
    }
}

In the implementing class B, interface A has not been changed from what "Moon" has provided, but method aMethod has been synchronized. So you will not be penalized for doing this. Class B is your thing, not "Moon"'s.
A more important thing is to consider on what you are synchronizing. If you create two or more separate instances of class B you are not synchronizing any resources used by those objects. Synchronization works only for multiple threads "going through" the same object.
However, you could synchronize a static method, in that case the synchronization is peformed on the Class object.

[Peter Yunguang Qiu]

Thanks Nicholas, Terry, Philippe, Andrew and Barry. You postings help me a lot.
The links that Terry post is very helpful.
Peter