• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Bodgitt and Scarper � implementation of the DBMain interface

 
Maciej Miklas
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!)
 
Maciej Miklas
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic