GeeCON Prague 2014*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Problems with DBMain interface 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 "Problems with DBMain interface" Watch "Problems with DBMain interface" New topic
Author

Problems with DBMain interface

Gytis Jakutonis
Ranch Hand

Joined: Feb 02, 2004
Posts: 76
Hello. I'm working on B&S Contractors assignment. I have beed given a concrete DBMain interface, which in some cases is not quite clear. The first problem is exceptions:
1. find(int recNo) throws RecordNotFoundException - looks strange for me, since find() is not addressing a particular record, so it can not face with missing record problem. The only situation I can figure out is problems with underlying IO(raf or channel). But I'm not sure if RecordNotFoundException is the correct exception for such situation(since we are not working with concrete record). So question is open - when does find() use RecordNotfoundException?
2. create() method throws DuplicateKeyException, but assignment tells nothing about this exception or any validation that must be performed in create(). Since database format does not support 'key' field inidicator, it is unclear that 'duplicate key' means? Does it include all fields checking, or just particular(but which one?) checking for duplicates?
3. This one is on locking. lock()/unlock() documentation states, that these facilities ensures that only lock owner can update() or delete() record. But on ohter hand update() and delete() documentation say nothing about locking. So there can be two resolutions of this issue: lock() and update(), delete() are completely independent facilities(i.e. update() does not check for lock) and are used by higher(business) level dtabase wrapper; or all of them are related(i.e. update() fails if no lock is held). Seems like many posts refer to the latter case, but the first one is quite reasonable too(in this case database layer is quite simple and allows everything, but business layer takes care of everything). Any comments on this?
Seems like quite a big post, so thanks in advance for your patience and answers.
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
Hi Gytis,

1. find(int recNo) throws RecordNotFoundException - looks strange for me, since find() is not addressing a particular record, so it can not face with missing record problem. The only situation I can figure out is problems with underlying IO(raf or channel). But I'm not sure if RecordNotFoundException is the correct exception for such situation(since we are not working with concrete record). So question is open - when does find() use RecordNotfoundException?

You can implement the find() method with searching with the recNo. In addition, you implement another find method that accept the arguments for the searching criteria (i.e. Contractor name, etc).
The RecordNotFoundException is encountered when the target record does not exist in the DB file. i.e. If you enter 101 while the DB contains only 100 record, then the record 101 is not found!
This can be extended to the arguments that the contractor name does not exist in the DB so that RecordNotFoundException is thrown.

2. create() method throws DuplicateKeyException, but assignment tells nothing about this exception or any validation that must be performed in create(). Since database format does not support 'key' field inidicator, it is unclear that 'duplicate key' means? Does it include all fields checking, or just particular(but which one?) checking for duplicates?

You can define the method to throw this exception, and perform a checking on the recNo. If the recNo is duplicates, then this exception is thrown. However, clearly that this exception will not be thrown anyway, as you can never create a duplicated key. Thus, I just document it.

3. This one is on locking. lock()/unlock() documentation states, that these facilities ensures that only lock owner can update() or delete() record. But on ohter hand update() and delete() documentation say nothing about locking. So there can be two resolutions of this issue: lock() and update(), delete() are completely independent facilities(i.e. update() does not check for lock) and are used by higher(business) level dtabase wrapper; or all of them are related(i.e. update() fails if no lock is held). Seems like many posts refer to the latter case, but the first one is quite reasonable too(in this case database layer is quite simple and allows everything, but business layer takes care of everything). Any comments on this?

You need to perform a record level lock. i.e. when performing update or delete, you can only do so if you hold the lock of that record. In some sense, other transactions cannot touch that record if they dont get the lock. This avoid the concurrent access of the same record. This really depends how you view this, and you should write this down in the documentation.
Hope this help.
Nick


SCJP 1.2, OCP 9i DBA, SCWCD 1.3, SCJP 1.4 (SAI), SCJD 1.4, SCWCD 1.4 (Beta), ICED (IBM 287, IBM 484, IBM 486), SCMAD 1.0 (Beta), SCBCD 1.3, ICSD (IBM 288), ICDBA (IBM 700, IBM 701), SCDJWS, ICSD (IBM 348), OCP 10g DBA (Beta), SCJP 5.0 (Beta), SCJA 1.0 (Beta), MCP(70-270), SCBCD 5.0 (Beta), SCJP 6.0, SCEA for JEE5 (in progress)
Gytis Jakutonis
Ranch Hand

Joined: Feb 02, 2004
Posts: 76
Thanks for replay. Seems like I've forgot to include more info on find and create arguments:
find(String[] criteria) - this one is not clear with record not found exc.
create(Strning[] data) - with this one is not clear that 'duplicate key' means.
as for locking, I understand and fully agree, that database layer should provide ability to lock record, since business layer will definitely need this functionality(lock + read + update + unlock sequence). The problem is that I'm not sure that locking should be automatically checked in database layer - maybe this should be left for business layer(i.e. database just provides locking functionality, while business class uses lock(), isLocked() etc. to ensure that only locked record will be modified).
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
Hi Gytis,
Since my assignment is URLyBird, I do not read B&S in fact. However, I believe that we are doing the same thing.

find(String[] criteria) - this one is not clear with record not found exc.

I assume that the number of criteria is actually the number of displayed fields. i.e. If there are 10 columns in the JTable, I assume that criteria.length = 10.
I simply did this. Assume criteria[0] and criteria[1] are the search requirement fields, say contractor name and location. Then, when you perform a search, only criteria[0] and criteria[1] contain the search value, while criteria[2] to criteria[9] are NULL. Then you know the search focus on name and location ONLY. Thus, you can then implement the search algorithm.

create(Strning[] data) - with this one is not clear that 'duplicate key' means.

Since the instructions do not mention the *primary key* of the record, thus, you can have either assumptions:
1. Assume the recNo (which is the sequence number of the record inside the data file) is the primary key. In such case, it is impossible for you to throw DuplicateKeyException, as you will create a record by appending it to the end of the file or replace a record that is mark deleted. In either case, nothing can be duplicated.
2. Assume the contractor name and location are the composite primary key. In such case, if the user provides a record that contact duplicate name+location, you throw this exception.
For me, I choose option 1, as it is a bit simpler.
But no matter which method you choose, you *should* put it down into your choice.txt. So that the grader will know what you are thinking.

as for locking, I understand and fully agree, that database layer should provide ability to lock record, since business layer will definitely need this functionality(lock + read + update + unlock sequence). The problem is that I'm not sure that locking should be automatically checked in database layer - maybe this should be left for business layer(i.e. database just provides locking functionality, while business class uses lock(), isLocked() etc. to ensure that only locked record will be modified).


This depends on what design pattern you used.
You have a DBInterface given by SUN. And SUN should ask you implement ALL functions declared in the interface using, say DBMain.java.
For me, I ONLY implement the *real* function in DBMain. i.e. For create(), I concat a string from the argument criteria[] and then write it into the file. NOTHING ELSE. For delete(), I marked the target record with the delete flag. NOTHING ELSE. So, in that layer, no locking concepts. The method focus on its function ONLY.
But then, I apply DAO pattern in it. I have defined a class, called DBServer. This is the TOPMOST class that the users can interact with. Users cant call the DBMain methods directly. Thus, when an user invokes delete(), DBServre first called lock(). If get the lock, then call delete(), else wait for the lock().
In such sense, you can then add-on your locking mechanism into it.
Does this make sense?
Nick
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Problems with DBMain interface