Where to use the lock/unlock methods?

Hi all,

I'm pretty new to Java and now I'm going to start to take some design decisions on my URLyBird 1.3.1 assignment. I followed this forum for the last three weeks and you all seem to be very helpful and for almost every question there seems to be an answer here.

What I couldn't figure out is - from the assignment and as well from several threads I read here - if it's mandatory to place the record based lock/unlock methods defined in the DBMain interface inside or outside the delete/update methods when implementing those methods in the Data class. Or is it up to the programmer?
I tend to place them outside. I would like to use a business layer with the tasks book and search. The task book then will use

lock - update - unlock

from the Data class to be thread-safe;) On the other hand, placing them outside and just coding the book and search task in the business layer, I won't provide the SUN-reviewers with thread-safe update, delete and create functionality - it would be up to them to combine my methods in the Data class accordingly. Is it OK to do so or is it not sufficient?

Hope you understood? Any opinions, experiences?

Thanks in advance
Harry

Harry Beck wrote:...outside the delete/update methods when implementing those methods in the Data class

It's up to you. You only have to explaining about your design choices, as you can see in other topics. I suggest only, that locking is not responsibility of your Data class. Your Data class must only to be the access point to database.

Howdy, Harry. In the name of the JavaRanch family, I'd like to give you a warm welcome!!!

What I couldn't figure out is - from the assignment and as well from several threads I read here - if it's mandatory to place the record based lock/unlock methods defined in the DBMain interface inside or outside the delete/update methods when implementing those methods in the Data class. Or is it up to the programmer?

Champion, in my opinion, the Data class is a place where you handle data. That means that there's got to be someone in an upper layer dealing with how things work, combining things so that the business rules are correctly applied. Calling the lock method from the update method is sort of mixing things. It isn't really the update method's responsibility to lock a record before updating it. Another thing is, we can't really tell how the assessor's tests are (I created one that I think that can sort of emulate them - you can find it here). So, I'd say that the best thing is to follow what seems to be the natural approach, that is, calling lock -> update/delete -> unlock.

I myself implemented a thick client, which means that I have a remote interface that looks pretty much like the one that was provided to me (and the same that was provided to you, because I also got the URLyBird 1.3.1). And I controlled everything remotely. This is sort of like using the Exposed Domain Model, and controlling transactions from the Web layer. If it was today, I'd implement a thin client, using the services provided in a remote interface (which would be more like a Façade), and having everything controlled on the server side, so the client's job would be easier. For this certification, your job is to make sure that your bookRoom() method works properly concurrently. But you'll also have to implement the create and delete methods in your Data class.

Another thing, please take a look here. I think it might be helpful! And whenever you have a doubt, please let us know!

Hi Johnny, Roberto

this is somehow exactly what I wanted to hear.

My doubts resulted from not providing thread-safe create/update/delete functionality directly and one solution to do so would have been to include the lock/unlock method in those methods. I rethought about it. You're right, it's not proper at all, the usage of the lock/unlock methods shouldn't take place in the Data class, but in an upper class.

Thinking in terms of a relational database lock/unlock corresponds to begin/end transaction. If we think of a transaction with more than one update/delete/insert statement (which is not the case in the assignment), the lock/unlock methods must not be placed inside.

Roberto, I as well tend use a thin client, thanks for your link to the testing class.

Thanks both of you for your input
Harry