aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes SCJD Design Discussion 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 Design Discussion" Watch "SCJD Design Discussion" New topic
Author

SCJD Design Discussion

Rob Symth
Ranch Hand

Joined: Apr 29, 2011
Posts: 32
Hello folks this is my first post to the Java ranch so be gentle
I am currently in the process of implementing my SCJD of which the assignment I received was B&S.
I would just like to discuss my overview design with the experts who partake in this forum.

To help me with the implementation I am using Monkhouse's SCJD book

From the GUI (via RMI or not) a DTO Contractor object will be passed to the business tier, from here the DTO is converted into a String [] & passed to the facade class which then passes it to the DB file access as a string [] in which DB CRUD operations can be performed, the I/F requires String [] & no DTO so I think its best to have the ContractorFIleAccess class work with String[] rather than creating a DTO in order for CRUD ops which to do again seems a bit wasteful, any comments on this?

Also with regards synchronization of the RAF DB the granularity of the locking was too fine specified in the SCJD book & I believe the Data File Access class to be not thread safe as we have two difference locks (1 lock for the DB RAF & 1 lock for the recordNoList) I decided to take a more simpler approach & to just synchronize the public methods of the DB File Access class which are create, read, delete, update & find although at the cost of some performance the simplicity & guaranteed thread safety outweighs this, any comments on this? alternatively I could introduce just the one Reentrant read/write lock for both the recordsNoList & the RAF DB??

One final point I made the assumption that in standalone mode we also have to be aware of concurrent access to the RAF DB from potential client on the network elsewhere

Thanks for your time to reading & responding
Rob
Marcel van den Boer
Greenhorn

Joined: Apr 19, 2011
Posts: 21

Rob Guess wrote:I made the assumption that in standalone mode we also have to be aware of concurrent access to the RAF DB from potential client on the network elsewhere

My instructions (URLyBird) specifically tell me I don't have to worry about this. I think this is mentioned in all assignments.

Otherwise, you pretty much describe what I have in mind for my project .

EDIT: And welcome to JavaRanch of course


OCPJP
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5535
    
  13

Hi Rob,

A warm welcome on the JavaRanch!

Rob Guess wrote:Hello folks this is my first post to the Java ranch so be gentle

We always are (I hope)

Rob Guess wrote:I would just like to discuss my overview design with the experts who partake in this forum.

I don't know if I qualfiy as one of the experts you had in mind, but I give it a shot

Rob Guess wrote:From the GUI (via RMI or not) a DTO Contractor object will be passed to the business tier, from here the DTO is converted into a String [] & passed to the facade class which then passes it to the DB file access as a string [] in which DB CRUD operations can be performed, the interface requires String [] & no DTO so I think its best to have the ContractorFIleAccess class work with String[] rather than creating a DTO in order for CRUD ops which to do again seems a bit wasteful, any comments on this?

No comments, which make sense because I followed the same approach (and had the same thoughts about using a String[] in Data class.

Rob Guess wrote:I decided to take a more simpler approach & to just synchronize the public methods of the DB File Access class which are create, read, delete, update & find although at the cost of some performance the simplicity & guaranteed thread safety outweighs this, any comments on this?

Again no comments because of similar approach. What are you planning to do with the other methods in the given interface (lock/unlock/isLocked)

Rob Guess wrote:One final point I made the assumption that in standalone mode we also have to be aware of concurrent access to the RAF DB from potential client on the network elsewhere

Already mentioned by Marcel van den Boer, so just to confirm: this isn't necessary because it's mentioned in the instructions and I quote "You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server.". I would be amazed if that sentence was not in your instructions.


Hope it helps!
Kind regards,
Roel


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Rob Symth
Ranch Hand

Joined: Apr 29, 2011
Posts: 32
Thanks guys for your comments!!
Good to see I am on the right track
Roel as regards your comments on lock/unlock/isLocked I plan to in my facade class delegate this to the ReservationManager which will have the appropriate logic to deal with the cookie specified in the interface & either wait with no CPU cycles taken up (if its already locked with a different cookie) or proceed with the call to the ContracterFileAccess (delete/update calls) or finally allow to unlock if in both cases the cookie is valid.

Thanks again
Rob
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: SCJD Design Discussion