aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes SCJD obstacles Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "SCJD obstacles" Watch "SCJD obstacles" New topic
Author

SCJD obstacles

Mandy Bowman
Ranch Hand

Joined: Jan 24, 2007
Posts: 32
Hello everybody,

I have been trying to do the exam for over a year now and am getting really stuck with a few topics, particularly threads and networking. For instance for the B&S project how does one determine which methods in the Data class require sychronized blocks and at where to put them? Also, I have no idea how to conduct the networking aspects of the project. I've read the Monkhouse book but am still confused.

I'm beginning to think that programming is not for girls.

Any help would be greatly appreciated.

Regards

Mandy
Mihai Radulescu
Ranch Hand

Joined: Sep 18, 2003
Posts: 918

Hi Mandy,

The data class uses a lock manager to guarantee concurrent access to the records. The lock manager can have synchronized blocks.

About the network you must be more precisely. Where you stack ?

Regards,
M


SCJP, SCJD, SCWCD, OCPJBCD
Mandy Bowman
Ranch Hand

Joined: Jan 24, 2007
Posts: 32
Hi Mihai,

Well regarding threading what I'm unsure about is which methods require synchronized blocks. For example there is a method called read(int recNo). Does this require a synchronized block and if so why?

As for networking I have decided to use RMI even though I have not used it before and all the descriptions I have read of it are complex. I have followed a tutorial but still have trouble coming up with a solution.

M
Mandy Bowman
Ranch Hand

Joined: Jan 24, 2007
Posts: 32
Hi Mihai,

Well regarding threading what I'm unsure about is which methods require synchronized blocks. For example there is a method called read(int recNo). Does this require a synchronized block and if so why?

As for networking I have decided to use RMI even though I have not used it before and all the descriptions I have read of it are complex. I have followed a tutorial but still have trouble coming up with a solution.

M
Erkin Kanlioglu
Greenhorn

Joined: Jun 06, 2007
Posts: 20
Hi Mandy

I will try to give some clue instead of giving straight response to your question.

First:
RMI will create seperate threads to handle connections and to execute your task.(Which means you will have race conditions for sure)

Second:
You have only one file to store information. That file must be consistent between threads.(You might have thought that read operation can be done in dirty read mode. But position pointer in file is NOT synhronized.)
Mandy Bowman
Ranch Hand

Joined: Jan 24, 2007
Posts: 32
all my file io code is done in a particular class and mu read method in my Data class calls this file io class's read method (which is synchronised). what i actually was wondering is do I need to have a synchronised block in Data.read when all it does is have a call to the other read method and a try catch and a return. if so what should be the scope of the synchronised block? the whole method?
rinke hoekstra
Ranch Hand

Joined: Apr 06, 2007
Posts: 152
Hi Mandy.

Every time you access the database file in any way, you need a synchronized block. So also in a read method, and even in the find method.

You should think of it like this: between every line in your code, and even inside a single line of code, another thread may intrude, and may steal your cpu time, and do its things.

So usually, when reading a record, you first count the amount of bytes by calling seek, and then you read the record. At basically every point in this process, another thread may intrude, and put the filepointer at some other place in the datafile. Result: wrong record read.

So all access to the database file, reading or writing, should be atomic, thus synchronized.

On threading, you can read my post which I recently put on this forum (http://www.coderanch.com/t/189169/java-developer-SCJD/certification/Locking-strategy-URLyBird-ReentrantLock), and which nobody actually replied on (hint, hint, hint!!).

Rinke


_ _ ________________________ _ _ <br /> <br />Just SCJP (but 93%)
Barry Gaunt
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729
Hello "Erkin K."-

Welcome to JavaRanch.

On your way in you may have missed that we have a JavaRanch Naming Policy for displayed (screen) names. Your displayed name must consist of a first name (or an initial), a space, and a family name (in that order) and not be obviously fictitious. Since yours "Erkin K.", does not conform with it, please take a moment to change it, which you can do right here.

Posters with nonconforming displayed names will be locked out of JavaRanch after a few posts using those names.

Thanks
-Barry

(NR) - search tag


Ask a Meaningful Question and HowToAskQuestionsOnJavaRanch
Getting someone to think and try something out is much more useful than just telling them the answer.
Mandy Bowman
Ranch Hand

Joined: Jan 24, 2007
Posts: 32
hi rinke, hint taken i will post my thoughts on your threads thread. please don't expect any ground-breaking analysis
Mihai Radulescu
Ranch Hand

Joined: Sep 18, 2003
Posts: 918

Hi Mandy

About the lock manager
You need a lock manager functionality, you can pack it in your Data class but I recommend you to build a separate class for it. The lock manger allows you to lock only one record and let the rest of the record available. In the lock manager you can use the classical synchronize mechanism or you can use the new
features from : java.util.concurrent package. Each of this have advantages and disadvantages, so you must take some decision here - and justify them.
This theme was commented here a lot of times, just make a search using the "Lock Manager" and you'll get a lot of inspiration sources.

About the network communication
You will need a (pluggable) transport layer, the purpose for this layer is to transport information between two points. The logic here is quite simple : client -> transport layer -> data. It is quite important that this layer is pluggable because you'll need to switch between the local and remote mode. The most of the people uses here an decorator here.
This theme was commented here a lot of times, just make a search using the "Transport Layer" or "Neetwork Client" or "Remote Client" and you'll get a lot of inspiration sources.

Regards
M
Mandy Bowman
Ranch Hand

Joined: Jan 24, 2007
Posts: 32
with regards to locking. My read method is here:



Now io.read is a method that is synchronised (it's method signature states that it is a synchronised method. My question is do I really need to have a synchronised block around this code? Is it not atomic enough to not neccesitate that? Also, would it not make the program slower to do that?
rinke hoekstra
Ranch Hand

Joined: Apr 06, 2007
Posts: 152
Hi Mandy,

If the io.read method itself is synchronized, then you don't need extra synchronization here, I would say.
Mandy Bowman
Ranch Hand

Joined: Jan 24, 2007
Posts: 32
that's exactly what im unsure about. Part of me thinks i do need it because what if while the io.read method is being called and hefore the assignment of the return value to the data variable if the current thread gets swapped out we will have a problem wont we?
Mihai Radulescu
Ranch Hand

Joined: Sep 18, 2003
Posts: 918

Hi Mandy

The read method is a non-destructive method so it is half so dangerous as the delete or modify. The read method only needs a synchronized access to your database file, this synchronized access can be a overhead because in the stand alone mode you don't need this feature. So you need to provide two kind of access to your database file, with the other words you need an extra plugable layer between your DAO (the Data class)and the database. something like :
Single client : Data - Data Access Layer -> DB File
Munti client : Data - Syncronized Data Access Layer -> DB File

Regards
M
[ June 17, 2007: Message edited by: Mihai Radulescu ]
Nina Binde
Ranch Hand

Joined: Sep 24, 2004
Posts: 85
Hi Mihai,

You mentioned it might be a overhead to use the synchronized DataAccess class for the single client. I think that since there is going to be one and only client accessing the methods in DataAccess, it shouldn't matter if the methods are synchronized or not. Agreed there might be a little overhead, but is it worth creating another DataAccess class just for the single client?
I am in the process of designing. So ,please let me know your opinions.
Mihai Radulescu
Ranch Hand

Joined: Sep 18, 2003
Posts: 918

Hi Nina

I like the expression :"little overhead" .
The point is you need a layer able to handle on the physical level with the database file, it is up to you to make it pluggable or not. But, just from the design point of view you provide a feature needed only in a particular case.

Regards,
M
Jeremy Botha
Ranch Hand

Joined: Feb 16, 2005
Posts: 125
Contrary to what other people are advising here, I elected NOT to synchronize read, mainly due to some rather nasty real-world experiences. heh.

Instead, I made sure that the update and insert business logic was intelligent enough to determine whether there'd been concurrent access on a record, and then notify the user. I justified all this in the documentation, and it appeared to satisfy the examiner. So it appears that as always, if you justify it well enough and it works, it should be acceptable to the examiner.

Incidentallly, my framework was of the following format:
Multi user application -> Network-aware abstraction layer -> Synchronized data access layer -> DB
Single user application -> Non-networked abstraction layer -> Synchronized data access layer -> DB

which is similar to the structure alluded to by Nina above. I also didn't see the benefit of different data access layers, and decided to rather do the abstraction one layer up. I justified this by pointing out that one could change the database backend and one would only have one point of modification in the application.

hope this helps!
J


McFinnigan? Never heard of him. Nobody here but us chickens...<br /> <br />SCJP for Java 1.4<br />SCJD for Java 5.0
Erkin Kanlioglu
Greenhorn

Joined: Jun 06, 2007
Posts: 20
Hi

In case of Jeremy's read method solution(Not synchronized), I think that you should open new files for every read operation...

Am I right Jeremy?

Cheers
Jeremy Botha
Ranch Hand

Joined: Feb 16, 2005
Posts: 125
Hi, Erkin.

From what I remember, my solution opened File access onto the file for every operation, not just read. I can't however remember the exact implementation details.

I don't however believe that this is strictly necessary, so long as all changes are immediately written to the data file.

J
Erkin Kanlioglu
Greenhorn

Joined: Jun 06, 2007
Posts: 20
A question from me regarding update operation...

let's just imagine

server is running to handle db side

First client connected to server
Search for x,y
Lock the record 5 for update by picking that record from JTable
Update dialog appeared with old data.

Second client connected to server
Search for x,y
Select same record as first client and click update button
Update dialog will not appear because record is already locked.
Main window of Second client will freeze as well till record is available.

My current implementation is like that becase of the lock method description
in the interface.(No CPU consumption anymore and wait till record is available)

If you think this is way we should implement, what should happen for following scenarios

1-) First Client update take so long time or first client crushed without
unlocking.
2-) if your response is give time limit to wait method and unlock it, how should i notify first client if it doesn't crush...

Cheers
Mihai Radulescu
Ranch Hand

Joined: Sep 18, 2003
Posts: 918

Jeremy,

If you choose to create a RAF for each operation (I deduce this from your post "my solution opened File access onto the file for every operation") you'll have a limited access on your db file because you can open only a limited number of files (file handlers). So for a given amount of nervous users (a nervous user does a lot of actions) your application will crash.
More, you must synchronize some how all the RAF instances, because all are using the same file - so you are back to the "old synchronize", the only advantage for this method is that each operation own it own file offset pointer (similar with the one from Andrew bock).


I don't however believe that this is strictly necessary, so long as all changes are immediately written to the data file.


Hmmm, it is really so, on every operating system ?

Regards
M
Mihai Radulescu
Ranch Hand

Joined: Sep 18, 2003
Posts: 918

Hi Erkin,

There are some possibilities here :
1.if the client crash it must release the locked record in a finally block
2.if this is not possible you need a client crash detection (if you user RMI you can try the Unreferenced interface).

The time out is dangerous because you don't know how your application will be used in the future, may be a junior programmer do some sleeps in its client and them suddenly it connection is gone.
My advice is to take care about the point 1 and to document the point 2.

Regards
M
Jeremy Botha
Ranch Hand

Joined: Feb 16, 2005
Posts: 125

If you choose to create a RAF for each operation (I deduce this from your post "my solution opened File access onto the file for every operation") you'll have a limited access on your db file because you can open only a limited number of files (file handlers).


Hi, Mihai.

This is from my (probably fuzzy by now) memory of what I did.

I failed to mention that from what I remember I closed the random access file immediately after performing whatever operation I needed to perform. Whether this is transactional in nature, and whether it behaves the same way in all Operating systems, I cannot answer.

I also ran several test scenarios against the file, using several threads which performed several thousand operations on the Data layer and could detect no concurrency or file-handle related problems under Windows XP, using JDK 1.5.0

Whether these would occur as I increased the number of operations I don't know, but within the scope of the application there were no apparent problems.

J
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: SCJD obstacles