Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

SCJD Design Discussion

 
Rob Symth
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 21
Java Linux Notepad
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Roel De Nijs
Sheriff
Posts: 9828
103
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Rob Symth
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic