Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Bodgitt and Scarper � implementation of the 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 "Bodgitt and Scarper � implementation of the DBMain interface" Watch "Bodgitt and Scarper � implementation of the DBMain interface" New topic
Author

Bodgitt and Scarper � implementation of the DBMain interface

Maciej Miklas
Ranch Hand

Joined: Feb 12, 2007
Posts: 61
Hi all,
I would like to confirm some design decisions.

Class visibility:
In my assignment is not stated that I should provide public implementation of DBMain interface. I made it (Data.java) package protected, because GUI is accessing this implementation trough RMI Fa�ade, which makes the methods a little bit easier to use.
Also constructors of thrown exceptions are made package protected. The exceptions itself are public, because they go to the client side.

File access:
The whole file access is synchronized � serial. This is the only possibility, which will guarantee, that reads will get no corrupted data. The problem is, that search is blocking write operations.

Search:
There is no indexing, so I have to go trough whole db file each time to find something.
I am using dirty reads of curse � search returns also locked rows

Data.java access:
Try to access update/delete the method without having a lock throws IllegalStateException. This is runtime, but there is not another possibility. The same about updating the row, that has been already updated.

Thanks for suggestions,
Maciej
Vincent Li
Greenhorn

Joined: Jan 12, 2007
Posts: 22
Hi Maciej,

The class visibility seems fine. That's pretty much the way I went. Can just state it in your choices.txt. I think that's perfectly valid to minimize exposure.

On file access, your reads should block writes. When a client is still reading the data, you don't really want it to be changing while your read.

I don't really understand what you mean by "search returns also locked rows". My interpretation is that it return rows that are "locked" with the lock() method, right? In that case, it's not a problem. Search is just reading the data. It's not going to modify it.

Can you expand a little more on the "update/delete...throws IllegalStateException"? I don't understand at all what you are trying to say here. Why would the locking on update/delete/create throw IllegalStateException?

Vince
SCJP(1.4), SCWCD(1.4), SCJD(almost there!)


Vince<br />SCJP(1.4), SCWCD(1.4), SCJD (5.0)
Maciej Miklas
Ranch Hand

Joined: Feb 12, 2007
Posts: 61
Thanks for the answer - I agree

In my interface the update/delete method can be executed without having a lock on the row - technically this is possible. I would like to prevent this. My method throws an exception in case of such call.

Regards,
Maciej
 
jQuery in Action, 2nd edition
 
subject: Bodgitt and Scarper � implementation of the DBMain interface