maybe its safer to write some data to the file amore often
Harry Henriques wrote:Personally, I think that using record caching makes your design more complicated.
How difficult is it to implement a try-catch block and wrap the IOException with a general RuntimeException?
The difficult part was implementing the IO (at the byte level) so that the data transfers didn't throw an IOException.
I probably spent one quarter of my total design time on the Data class.
Roel De Nijs wrote: I don't really know what you exactly mean with Does your Data class interface with the record cache or does it interface with the flat-file database?.
Roel De Nijs wrote:the Data class (because it is a singleton)
Roel De Nijs wrote:Maybe I don't understand what you exactly mean (again), but when I wanted something to be written to my database file, I just used RandomAccessFile.write(bytes);. And if it throws an IOException, I just threw a custom exception.
I don't have a clue about how they test, but I think they don't use an automatic test, because else it would also fail when you apply singleton pattern on your Data class (your constructor is private, so Data data = new Data(); will fail too (so you would fail too ). I have lots of javadoc explaining how my API (interface) should be used. And when you call a method on the Data class, before invoking the start-method you will get an IllegalStateException indicating the start-method should be called prior to any other method.how do the assessors test your Data class when you have introduced read/write methods, which handle record caching, that aren't supplied in the assignment interface?
This intelligent format was nothing less than a String[], because all methods from the given interface has String[] in its signatures. In my business service I convert this String[] to a transfer (value) object (a simple pojo), and vice versa of courseYou still have to deal with getting the data into the HashMap in an intelligent format.
For every record I first read the "deleted" flag and then I read the complete record (I ask RAF to read a byte[] with a length equal to the record length). Then I pass this array to a custom (private) method which converts this byte[] to a String[].Reading and translating the flat-file database for record caching isn't all that simple.
Roel De Nijs wrote:I think they don't use an automatic test, because else it would also fail when you apply singleton pattern on your Data class
A complete overview of the amount of code and comments I needed for my assignment can be found here. My Data class has in total 760 lines (code, comments and blank lines all included).My Data class and DataUtils are comprised of 1400 code lines and comments.
I just iterate trhough my record cache: if the value is null, the record is deletedOne very large problem with my method is that I first had to scan the database on the hard disk to determine if a record had been deleted
I 'm not a moderator of this forum, because everything I say about the SCJD assignment is true or should be considered as the "standard". Following your own lead is a positive thing, so (certainly with an open assignment as this one).But at the time I made my decision, you were not the forum moderator. You were just another blogger like myself. I usually follow my own lead, unless an authority tells me differently. When I made my choice, you weren't an authority, and I wasn't sure that your method could be trusted to satisfy the assessors.
Locking
Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above. 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. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.
Locks a record so that it can only be updated or deleted by this client.
// Reads a record from the file.
SCJP 6, SCWCD, SCBCD, SCJA
Orestis Salinger wrote:since this is my first post I need to thank all of you guys for this great forum.
You spend so much time answering all those questions in a very polite and professionell way. So to me it is always a pleasure to read. Thank you so much!
Orestis Salinger wrote:Do they really want me reading directly from file every time readRecord() is called ?
Is there any room for interpretation (e.g. Reading the database file feeded HashMap can be interpreted as "Reads...from file").
SCJP 6, SCWCD, SCBCD, SCJA
SCJP 6, OCMJD6
you don't have to handle any IOException in CRUD-methods, which you have to handle
Also you have to make sure that when write to database fails, the record in the cache is not updated/changed (I don't say it's hard to do, but it's something you -and a junior developer- have to think about).
In my opinion using a cache has little benefit
SCJP 6, OCMJD6
Olu Shiyan wrote:
Roel De Nijs wrote:In my opinion using a cache has little benefit
I believe my find and read methods still benefit greatly from this approach - they just read the cache.
I believe my find and read methods still benefit greatly from this approach - they just read the cache.
SCJP 6, OCMJD6
Olu Shiyan wrote:The only difference between how I use mine is that I call a 'persist' method in my create , update and delete methods. This doesn't make the code any complex.
you -or another developer- has also to think about how to keep the cache and the database file in sync,...
SCJP 6, OCMJD6
Roel De Nijs wrote:In fact using a Data class singleton with a record cache and marking every method synchronized will result in the simplest and easiest to understand (for the junior programmer) code possible.
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:Hi Roel, is this what you did with your solution - make every single method in your Data class synchronized?
Sean Keane wrote:I'm guessing this solution avoids the need for a lock manager?
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Roel De Nijs wrote:
Sean Keane wrote:Hi Roel, is this what you did with your solution - make every single method in your Data class synchronized?
Yes, that's what I did.
Sean Keane wrote:I'm guessing this solution avoids the need for a lock manager?
I don't know what you exactly mean with "lock manager", but I still have to keep track of which record is locked by which client.
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Thread t1 : lock : entering to lock record 1
Thread t1 : lock : locking record 1
Thread t2 : lock : entering to lock record 1
Thread t2 : lock : record 1 already locked, waiting...
Thread t1 : unlock : entering to unlock record 1
Thread t1 : unlock : unlocking record 1
Thread t2 : lock : finished waiting...
Thread t2 : lock : locking record 1
Thread t2 : unlock : entering to unlock record 1
Thread t2 : unlock : unlocking record 1
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
The current thread must own this object's monitor. The thread releases ownership of this monitor and waits until another thread notifies threads waiting on this object's monitor to wake up either through a call to the notify method or the notifyAll method. The thread then waits until it can re-obtain ownership of the monitor and resumes execution.
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:Ok, I think I just proved I don't understand how synchronized methods operate when a thread currently in a synchronized method goes into the waiting state (I knew I posted too soon !!!).
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |