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: Contractor, can I change the method modifier of Data?

 
Bigwood Liu
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Considering thread safety, I think the public methods in interface DBAccess should have synchronized key word when I implement it in Data class. For example,

Need your comment,
Regards,
Damu
[ September 14, 2003: Message edited by: damu liu ]
 
Bigwood Liu
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
need your help!
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi damu,
Mmh, it seems there are not many people today on the ranch...
You need some synchronization in Data, but the way you'll achieve it actually depends on your design.
Is your Data class a singleton (a single instance shared by all clients) ?
If true, the keyword synchronized used in the method signatures does the job : each of them equals to a synchronized(this) block on the whole method, where "this" is a shared monitor. OK.
If false (each client gets indirectly its own Data instance), your synchronized keyword has no effect. You need to synchronize on some common object. The latter may be static if your design is mono-table.
Now, do you need to synchronize (in some way) all your methods ? No, or anyway not in the same way. For example, think of the lock() / unlock() methods as some level of synchronization per se, which should synchronize on some locks container (for example a HashMap), but surely not on a Data instance, even shared : while a caller would wait on a lock (automatically releasing its "lock" on the locks container), it would block all concurrent accesses to Data for all methods synchronized on it, maybe letting them hang forever (deadlock).
Synchronizing in the db package is the most challenging part of it IMO. Think of it carefully, in a way which fits in your global db design. Avoid nested locks as far as possible (it's not always the case), and if you need them, make sure that you got all of them "under control".
Maybe think of a possible solution allowing multiple concurrents reads guarded against single writes ... but it would probably go beyond the scope of this assignment.
Think of all that, and don't hesitate to come back with questions about it.
Best,
Phil.
[ September 14, 2003: Message edited by: Philippe Maquet ]
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Damu,
Phil wrote as follows in response to your question:

Avoid nested locks as far as possible (it's not always the case), and if you need them, make sure that you got all of them "under control".

Max's good book advises to avoid nested locks, period.
Think through your locking strategy and if you find yourself headed towards nested locking through synchronization, you are headed down the wrong path!
Regards.
Bharat
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bharat,
Max's good book advises to avoid nested locks, period.

Think through your locking strategy and if you find yourself headed towards nested locking through synchronization, you are headed down the wrong path!

... and I recently read some professional (actually) piece of code (unfortunately, I cannot remember where I saw it, but I'll keep that in mind), where locks were nested. I use a (very) few nested locks myself which are justified by design.
Max's book is not good, it's great ! And I think that am one of its best supporters. Max favours simplicity and safety and it's very defendable, but he also argues in favour of opening / closing the db file each time you need to read or write a record which is less.
It's impossible to me to argue against both your sentences, because there are "believers" arguments, and I don't like "Faith" (or "belief" - not sure of the right word) too much as far as software is concerned.
Best,
Phil.
 
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
Damu,
The synchronized keyword does not change the method signature.
You can add "synchronized" to your methods in Data class without changing the signature in the interface - try it and see.
Regards, Andrew
 
Bigwood Liu
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, thank you,
I am planning to use only one Data instance, and want to use RandomAccess to read and write database(I am not familiar with nio). So I think synchronized should be used. I will try to use it in the method in synchronized block.
Thank you once more,
regards,
Damu
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew and damu,
damu:
I am planning to use only one Data instance ... so I think synchronized should be used.

Perfect. With one shared Data instance, synchronized will work and your solution is simple.
Andrew:
You can add "synchronized" to your methods in Data class without changing the signature in the interface - try it and see.

What did you meant exactly ? "synchronized" is an implementation keyword, right ?
Best,
Phil.
 
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 Philippe,
I mean that the signature used to match the method to be used with the method being called in another class is <access modifier> <type> name(<parm type>*). The other (non access) modifiers do not alter the signature for matching methods.
An interface is only allowed to specify access modifiers before method declarations.
From the JLS:

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
 
Tony Collins
Ranch Hand
Posts: 435
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nested Locks may be bad but I think you actually need to use nested sychronization when implementing the lock method. I wasn't keen but there seems to be no other way.
Tony
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic