URLyBird DB Locking

[Cathal Mullan]

Hey Guys,

I have taken a look at some posts regarding the URLyBird DB locking, I see that people are returning lock keys to the front end.

I am wondering why people are doing this?

My plan is to have a thin client that connects to an RMI server. Behind this I will have a business layer.

In this business layer I was going to:

1. Get the lock for the record
2. Check the record has not been changed since it was retrieved
3. Update the record
4. Release the lock

So no returning lock keys to the front end.

Did anybody who passed the OCMJD do this too? Or am I missing something important?

cheers

[Roel De Nijs]

It all depends of course on the interface you've got. For example my interface does not have a lockCookie, so I had to come up with a slightly different approach. But for a thin client you don't need to pass the lockCookie back to the client, all the magic can happen on the server.

[Cathal Mullan]

Hey Roel,

my services interface would be something like:

public interface RoomServices {
    List<Room> find(SearchRQ request);
    List<Room> findAll();
    void update(Room room);
}

so no lock keys returned to the front end, seem ok to you?

cheers

[Roel De Nijs]

Lacks some business exceptions, but that's not the point here Seems ok to me

[Cathal Mullan]

Cheers for the advice, just want to make sure I don't get an automatic fail

[Roel De Nijs]

Just remember: I am not an accessor, so there is no guarantee that the given advice will not result in automatic failure. If you violate a must requirement, you'll fail (automatically). For all other decisions there is no good or wrong, just document your decisions in choices.txt and you'll be fine (and an OCMJD soon)

[Cathal Mullan]

Hopefully

cheers