B&S: update method responsibility

Hi All;

my Data Access class called Data.java and the following is the method signature:

and in the db description section for the owner field is : ... if this field
is all blanks the record is available for sale.

my question is:

regarding my update method responsibility :
- check the availability of record number.
- check if this record number is valid not deleted.
- if so update the record.

is it this pre-check enough, or i must make the update method also check
if the request available for book , ex : check if the owner is empty or not ???
i think that if i don't check that , then any client can update and book
the record .

Best Regards all.
m_darim.
SCJP, SCJD in progress ...

Hi,

you're making me doubt now...

For me "booking" is higher level than the database. The update method at the Data level is blindly updating each field.

regards,
Alex

hi Alex;

consider the following step when sun test software use your ADO:

Client A : lock record 2.
Client A : attempts to update record 2.
Client A : unlock record 2.
Client B : lock record 2.
client B : attemptls to update record 2.
client B : unlock record 2.

so how the client B update know that the Client A had update and book the
records.
in my mind i with you the book in higher than update, so what the
purpose of the lock and unlock if any update will update previous update!!

BR;
m_darim.
SCJP, SCJD in progress ...

Hi,

the purpose of the lock is to make sure concurrent update of the same record happen at the same time.. (or else corruption of the data).

If you forget about the "owner" field, just think of any field, it should be allowed to do the following:

- lock(2)
- change location from "Beijing" to "Hong-Kong"
- unlock(2)

- lock(2)
- change location from "Hong-Kong" to "Singapore"
- unlock(2)

If I look at the interface from SUN, each field have the same behavior at the database level. That is my understanding.

The logic to forbid updating the field "owner" twice is handled in my business logic, something just on top of the data layer (for me). For info, in the business logic, I also make sure that the client holds the latest information on the record he's about to "update", or else I forbid the update.

Regards,
Alex

hi Alex;

so you implements the book in business logic not at DB tier, i think you are true and i will comments that in the choices.txt document, but i imagne the following :
(note that : your DAO will be used by another software you don't see it at
all):

- lock(2)
- change owner from " " to "12345678"
- unlock(2)

- lock(2)
- change owner from "12345678" to "87654321"
- unlock(2)

BR;
m_darim
SCJP, SCJD in progress ...

Hi,

exactly, and the fact that the DAO can be reused is a reason that this logic should not (in my opinion) be implemented in the DAO itself.

This way, you can create another Business class/method to handle that *other* client with its own business rules, but still using the same database.

I think it would raise some problem however, if these rules should go against each other, but until then, we're safe

I think we could imagine in the future some users having higher credential and then being allowed to overwrite any "lower credential" booked record. The business layer would easily handle that..

Regards,
Alex

hi Alex;

Very thank for your response. i will implement what you suggest and document
it, and if i fail in the SCJD so the reason is you and only you

BR;
M_darim.
SCJP, SCJD in progress ...